Recent searches
Search options
Administered by:
It feels like a design flaw in the #Node resolution algorithm that packages and files are effectively indistinguishable and it messes up file path semantics. For example:
```
// Imports from `./foo.js`.
import './foo.js';
// Imports from `node_modules/foo.js/index.js`
import 'foo.js';
```
The fact that `foo.js` means something *completely different* from `./foo.js` feels like it's violating a fundamental invariant of #Unix file paths.
I find myself having to add pointless `./` paths all the time just to get Node resolution to look for a file and not a package.
@develwithoutacause@techhub.socialFrom my understanding you can basically put any file character except a slash in a #Unix file path, so fundamentally any input which accepts both a package and a file is fundamentally ambiguous. The only way to avoid that would be something like:
```
import 'pkg:foo.js';
// VS
import 'file:foo.js';
```
(And `file:` needs to be *required* for file paths.)
I do feel like it could at least be made less of an issue if #NPM packages had a special character convention. For example, if the leading `@` was required even for unscoped packages, then you'd import with:
```
import '@foo.js'; // Package
// VS
import 'foo.js'; // File
```
Ultimately you could still name a file `@foo.js`, so there is definitely ambiguity. However it would be significantly less common of an issue in practice.
@develwithoutacause I believe the rule on Linux is that you can have any bytes in a filename other than '\0' and '/'. So ASCII bell character, unicode RTL override, or byte sequences that aren't valid as UTF-8 are all fair game.
In practice you don't necessary want to support any technically valid filename in a context like this. And you should probably avoid filenames that are invalid on other common filesystems and OSes.
@ids1024 Yeah, I know #Linux is very flexible in what is technically allowed in file names. Of course how many tools handle them correctly is a different question.
In practice there definitely should be some constraints, particularly for cross-platform support like you mention. If you a file a bug that one of my CLI tools doesn't properly handle an ASCII bell in the file name I'll laugh the bug closed.