Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Correct module real path resolution #1696

Merged
merged 2 commits into from
Jan 25, 2021
Merged

Correct module real path resolution #1696

merged 2 commits into from
Jan 25, 2021

Conversation

paztis
Copy link

@paztis paztis commented Mar 24, 2020

  • supports the monorepo correctly
  • correct the no-extraneous-dependencies usage

JEROMEH added 2 commits March 24, 2020 09:03
…odule real path resolution

add real support of isAbsolute (windows + unix support)

importType refactoring: use the real resolved package path to check if external of internal, and not the name only like before: in case of monorepo, external modules are not under node_modules due to symlink but still out of the module.

correct tests node_modules dependencies to really provide teh package.json like in real usage

correct no-extraneous-dependencies rule: get the real name from the resolved package.json. If not aliased imports (alias/react for example) will not be correctly interpreted

change path import

add real support of isAbsolute (windows + unix support)

correct no-extraneous-dependencies rule: get the real name from the resolved package.json. If not aliased imports (alias/react for example) will not be correctly interpreted

even externals like "a/file.js" must not use extension.
only module names like 'module.js' and '@scope/module.js' are allowed

correct bad external definition: must be the folder path under the root of the module.
Here the module root is test folder, not cycles folder
@coveralls
Copy link

Coverage Status

Coverage decreased (-2.003%) to 95.795% when pulling d33d69d on paztis:master into efb5f07 on benmosher:master.

2 similar comments
@coveralls
Copy link

Coverage Status

Coverage decreased (-2.003%) to 95.795% when pulling d33d69d on paztis:master into efb5f07 on benmosher:master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-2.003%) to 95.795% when pulling d33d69d on paztis:master into efb5f07 on benmosher:master.

@coveralls
Copy link

coveralls commented Mar 24, 2020

Coverage Status

Coverage decreased (-0.1%) to 97.868% when pulling 802ce7d on paztis:master into 196d655 on benmosher:master.

@paztis
Copy link
Author

paztis commented Mar 24, 2020

Not sure to understand why, but I have this CI build that fails only on node v10: https://ci.appveyor.com/project/benmosher/eslint-plugin-import/builds/31684756/job/7lv7l952s32a8qx7

It crash on resolving the .babelrc of the webpack resolver. I don't change this part.
I've try to use a real JSON for babelrc ({"extends": "../../.babelrc"}) but result is the same.

Understand the issue ?

Coverage decrease is because of the fallback on no-extraneous-dependencies we never pass in (it might never apperas in reality, but I keep it for security)

package.json Show resolved Hide resolved
../../.babelrc
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this was a symlink; why did this file change?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this file import was failing on ApVeillor in case of node v10.
I try to replace its content with

{
  "extends": "../../.babelrc"
}

to avoid symling problem, but still present, so I rollback it.

I think the extension is a better way as the symlink for local development

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change should still be reverted

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know how to commit a sYmlinked file. can you do it after the merge ?

src/core/importType.js Outdated Show resolved Hide resolved
src/core/importType.js Outdated Show resolved Hide resolved
src/core/importType.js Outdated Show resolved Hide resolved
src/core/importType.js Outdated Show resolved Hide resolved
src/core/packagePath.js Outdated Show resolved Hide resolved
@paztis
Copy link
Author

paztis commented Mar 25, 2020

review changes applied

@paztis
Copy link
Author

paztis commented Mar 28, 2020

Any new for the PR approval ?

@paztis
Copy link
Author

paztis commented Apr 2, 2020

No news: start to be impossible to continue without thiese fixes
I will publish my custom version of eslint-plugin-import in case of no news :(

@paztis
Copy link
Author

paztis commented Apr 8, 2020

any news ?

@jimisaacs
Copy link

+1

@geoffp
Copy link

geoffp commented Apr 15, 2020

Looking forward to this!

Copy link
Member

@ljharb ljharb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the delay :-) i've reviewed this from scratch; apologies if you already answered some of these questions

../../.babelrc
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change should still be reverted

src/core/importType.js Outdated Show resolved Hide resolved
src/rules/extensions.js Outdated Show resolved Hide resolved
src/rules/extensions.js Outdated Show resolved Hide resolved
src/rules/no-extraneous-dependencies.js Outdated Show resolved Hide resolved
tests/src/core/resolve.js Outdated Show resolved Hide resolved
tests/src/rules/order.js Outdated Show resolved Hide resolved
tests/src/rules/order.js Show resolved Hide resolved
@paztis
Copy link
Author

paztis commented Jul 29, 2020

Hi

I review all the changes.

I've only problems with the babelrc file: I cannot commit the original symlink (don't know how to do it). Can you fix it on your side after the merge ?

For the files/symlinked-module change, it is because my module resolution is now really looking at the root package path + folder name, and not only test if the folder name is in the path.
I your unit test, as there's a package.json under the folder tests/src/files, it is considered as the root, and not tests folder as you imagine.
Forced to remove it.
Potentially you may reorganize all the test files under correct folder structure, with correct package.json like in reality.

Please tell me if there's missing things

@SanjiKir
Copy link

Hey guys, will this PR resolve #1832? I have the same problem with import/named in monorepo structure. It doesn't work for yarn workspaces.

@paztis
Copy link
Author

paztis commented Jul 31, 2020

No, I think. It only verify the import path is correctly written. Not it the content of the import is good.
We pack can do it potentially. Or typescript

@SanjiKir
Copy link

@paztis Yeah we are migrating to TS so far, so it will take some time since the project is huge. I didn't get the last sentence of yours
We pack can do it potentially. What do you mean by that?

@paztis
Copy link
Author

paztis commented Jul 31, 2020 via email

@paztis
Copy link
Author

paztis commented Aug 5, 2020

@ljharb what is the review status now ?

@caseyWebb
Copy link

@paztis I found your fork on npm, but how can I actually use it?

I added "plugins": ["@paztis/eslint-plugin-import"] to my .eslintrc, but I can't figure out how to configure rules. e.g. "import/order", "@pastiz/eslint-plugin-import/order", and half a dozen other combinations all throw "Definition for rule was not found" errors.

@ljharb
Copy link
Member

ljharb commented Aug 25, 2020

@paztis would you mind rebasing this on top of latest master (which will remove all merge commits) and ideally condense the commits? There's 34 right now.

I can handle #1696 (comment) for you after that's done, and give it a fresh review.

@paztis
Copy link
Author

paztis commented Aug 25, 2020 via email

@paztis
Copy link
Author

paztis commented Aug 27, 2020

@ljharb rebase on top of master is done now. I've verify the final content is exactly the same as on my old branch.
You can do the merge ?

@michaelfarrell76
Copy link

so excited for this! thank you all so much 🙏

@paztis
Copy link
Author

paztis commented Sep 3, 2020

Me too ^^
@ljharb any news for the merge ?

@ljharb
Copy link
Member

ljharb commented Sep 5, 2020

@paztis thanks! I've rebased this PR.

I've split out the isExternalModule bugfix into its own commit. That commit includes a test for order that fails without the fix, but i can't come up with a test for extensions that fails without the fix. Got any ideas?

Also, the second commit is quite large, so it's hard to me to understand everything it's doing. Can any parts of it be split into separate commits, that could land "first" - before the primary fix in the PR?

@paztis
Copy link
Author

paztis commented Sep 5, 2020 via email

@paztis
Copy link
Author

paztis commented Sep 17, 2020

@ljharb, any news ?

@buchanaf
Copy link

Hey guys (@ljharb and @paztis ), really looking forward to having this support. Is there anything I could do to help speed this along so this PR doesn't get lost in purgatory?

@paztis
Copy link
Author

paztis commented Oct 20, 2020

I don't know in fact. I'm still waiting the approval for the merge.

@ljharb ljharb merged commit 802ce7d into import-js:master Jan 25, 2021
@michaelfarrell76
Copy link

thanks for merging this! @ljharb any idea when a new version will be published to npm?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

9 participants