CompilationUnit.directive.stringValue Strips Path Separators on Windows

[BenAuerDev]

CompilationUnit.directives.uri.stringValue behaves inconsistently across platforms. On Windows, path separators in part and part of directives are stripped, whereas on Linux, they are preserved.

Current Behavior
For the following directives in Dart code:

part '../filename.dart';
part 'sub_dir/filename.dart';

part of '../filename.dart';
part of 'sub_dir/filename.dart';

• Linux Output:
  ../filename.dart and sub_dir/filename.dart

• Windows Output:
  ..filename.dart and sub_dirfilename.dart

Expected Behavior
For the above directives:

• Linux Output (unchanged):
  ../filename.dart and sub_dir/filename.dart

• Windows Output:
  ..\filename.dart and sub_dir\filename.dart

sdk version: '>=3.3.0 <4.0.0'
analyzer: '^6.0.0'

Related Work:
I encountered this while I was working on a PR at serverpod where I tested generated code using CompilationUnit and comparing CompilationUnit.directives.uri.stringValue to the expected path.

This test worked fine on Linux but failed on Windows due to the inconsistency.

Log of the directives of the CompilationUnit in windows:

Log of directive.uri.stringValue on windows:

Log of directive.uri.stringValue on Linux:

If I can help with any further information, you can holla at me any time 💪

[bwilkerson]

I don't know why it would be behaving differently under Windows, but it shouldn't be, so there's definitely a bug.

But there might also be an incorrect expectation. When you execute compilationUnit.directives[i].uri.stringValue (I added an index operator because directives returns a list, and uri isn't defined on List) it should return the content of the string literal without any change based on what platform you're running on. In other words, I would expect that you would get ../filename.dart and sub_dir/filename.dart on both Linux and Windows.

[srawlins]

(Side note: also interesting to get the literal string content as the string can be a concatenation of adjacent strings. E.g. this is legal: import 'package:path/' """path.dart""";)

[srawlins]

@BenAuerDev thanks for the detailed report. Is there a way to get a minimal reproduction case? I'd basically like to see "Here's the Dart source with an import with a slash in it" and "Here's what compilationUnit.directives[i].uri.stringValue returns for that source." It seems like this bug would have been caught by our unit tests, which are run on both UNIX systems and Windows.

[BenAuerDev]

I don't know why it would be behaving differently under Windows, but it shouldn't be, so there's definitely a bug.

But there might also be an incorrect expectation. When you execute compilationUnit.directives[i].uri.stringValue (I added an index operator because directives returns a list, and uri isn't defined on List) it should return the content of the string literal without any change based on what platform you're running on. In other words, I would expect that you would get ../filename.dart and sub_dir/filename.dart on both Linux and Windows.

Ah 💪 That would make my use case even easier if the returned value is the same on windows and linux

[BenAuerDev]

@srawlins Unfortunately I don't have access to a windows machine currently. I only came across it when running a test at serverpod which worked locally on linux, in the pipeline on linux but failed on windows in the pipeline.

I can see if I'll be able to set up a VM with windows and try it there, or maybe borrow a windows machine when I'm visiting family over the holidays 💪

[BenAuerDev]

Hello @srawlins,

I managed to get a minimal reproduction case, I tested it via the serverpod pipeline:

test(
    'CompilationUnit.directives[i].uri.stringValue returns relative path without separators on Windows.',
    () {
  var content = Platform.isWindows
      ? "part 'sub_dir\\example_child.dart';"
      : "part 'sub_dir/example_child.dart';";

  var unit = parseString(content: content).unit;

  var directive = unit.directives.whereType<PartDirective>().first;

  var directiveStringValue = directive.uri.stringValue;

  var expectedPath = Platform.isWindows
      ? 'sub_direxample_child.dart'
      : 'sub_dir/example_child.dart';

  expect(directiveStringValue == expectedPath, isTrue);
  });

[lrhn]

(Just for the record, the part 'sub_dir\\example_child.dart'; is not a valid part directive. Or at least not equivalent to part 'sub_dir/example_child.dart';. The strings should contain an RFC 3986 URI reference, and those only allow / as path separators. A backslash is not allowed in RFC 3986 URIs at all. The Dart Uri class is a little more forgiving and replaces \s with /s in most cases, and since the compilers use that class, some invalid URIs are accepted. That doesn't mean that they're valid. Don't use backslashes in import, export or part directives!)

[BenAuerDev]

Thanks for the information about URI standards, @lrhn. That's a helpful clarification regarding best practices for cross-platform compatibility.

To clarify the issue I'm seeing, it's not so much about the validity of backslashes themselves in the string literal. Instead, on Windows, CompilationUnit.directives.uri.stringValue seems to be actively removing the path separators (both forward and backslashes), resulting in a string without them. This inconsistent behavior, where separators are preserved on Linux, is what's causing the unexpected test failures.