Doesn't resolve index.js files correctly
See original GitHub issueThanks for such an awesome tool!
Our project had a src/constants/index.js
file with a bunch of named exports.
These named exports were imported in components within src/components
with a specifier something like ../constants
, and shrimpit was assuming this means ../constants.js
and didn’t bother looking for ./constants/index.js
like Node.js and other tools do.
This resulted in all our constants reporting incorrectly as unused.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:2
- Comments:5 (5 by maintainers)
Top Results From Across the Web
How to use index.js file(Properly) - DEV Community
this can be solved by using the index. js file only to export. import React from 'react'; const SomeComponent = () => {...
Read more >Why you should avoid index.js? - Medium
Answer: avoid index.js and import only what you need from where you need it. in our case, importing Item1 and Item2 from the...
Read more >VSCode doesnt pull the index.js when I load the index.html
If I use the developer tools, and look into sources, I find my index.js file has not loaded correctly. Has anyone else run...
Read more >index.js files are not resolved in imports
actions' would actually resolve index.js file if it exists. ... Doesn't it? 'Directory' imports are correctly resolved to me.
Read more >Watcher doesn't see a new file called "index.js" inside ... - GitHub
Refresh browser. You get the error. Change the import in the root index.js to ./App/ or ./App/index ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I ended up writing from scratch and publishing
find-unused-exports
; A Node.js CLI and equivalent JS API to find unused ECMAScript module exports in a project.It can resolve index files, custom extensions, etc. One thing I was not expecting was for it to be so fast —
find-unused-exports
takes less than a second for our project whereas Shrimpit for some reason takes quite a few minutes. It also supports ignoring specific exports known to be unused (e.g. the default export for a Next.js page) via ignore comments, making the tool fit for use as part of the test script for CI.The strategy is to not attempt to guess the absolute import file paths at the time they are discovered, but to record the import specifiers more faithfully:
Then later when analysing what exports are unused, search for the files in the list, resolving file extensions and index files in order of preference (it’s good to match the Node.js resolution algorithm).
Rather than do a fork and draft PR, here are the relevant diffs (minus updated tests and snapshots)…
https://github.com/yamafaktory/shrimpit/blob/64866939edf724f0aacd2fb39373241fe36d03b6/lib.js#L282
That’s not the best way to write it; this was just my work in progress to patch the way the code currently works.
https://github.com/yamafaktory/shrimpit/blob/64866939edf724f0aacd2fb39373241fe36d03b6/lib.js#L410
A side note: I avoided using
this.joinPaths
; it’s better topath.join
directly. Unhelpful methods like this could be removed to simplify the code and make it easier to understand what’s going on:https://github.com/yamafaktory/shrimpit/blob/64866939edf724f0aacd2fb39373241fe36d03b6/lib.js#L207-L209
I think namespace imports were not working at the time I abandoned the effort? I’m struggling to remember to be honest it was a few weeks ago.