Closed use-strict closed 4 years ago
This is a good finding however the fix is not coming and I think I'm going to archive the project soon. The reason is that the tslint
project itself got deprecated and the current state of the rule still fits my needs.
import("src/....") a) b) c) d)
I think I put it this way because I normally set baseUrl
to "."
, no any paths
records required.
Thanks for the update. Until I am able to find an equivalent rule for eslint, the following hack workaround worked, if anyone else bumps into this problem: !*(../)submodule1/**
whitelists the submodule1/
folder, for both cases of relative/non-relative path. It isn't perfect and it assumes there isn't another folder with the same name nested, but it does the job.
My project's tsconfig has a
baseUrl
set tosrc
and the folder structure looks like this:Some example import patterns:
I looked at the rule's source code and noticed the following: when the linting rule iterates the import statements and sees something that doesn't start with
.
(import paths likesubmodule1/*
), then it insists on doing something likepath.relative("src", "submodule1/someFile")
, which just ends up resolving to../submodule1
instead ofsubmodule1
. This is regardless of setting thebasePath
option or not.I see this behavior is also reflected in the test fixtures, with imports like
import("src/....")
. This however doesn't make much sense to me. TypeScript would not even resolve such imports unless a) thebaseUrl
is set to the parent ofsrc
, notsrc
itself b) There is an entry in tsconfigpaths
mappingsrc
to some other folder c)src
is an actual node module d) themoduleResolution
option is set to classic instead of node (which has been deprecated for a long time)Either way, depending on the type of import path (relative or not) we end up with two different behaviors, which is IMHO a bug.