import-js/eslint-plugin-import

Cannot resolve path for various modules when `require`d

adamlui opened this issue · 9 comments

In this workflow run for adamlui/js-utils@62ad0ab

Image

... there are a bunch of false positives for various require'd working pkgs when import/no-unresolved's commonjs is set to true

ljharb commented

All all these packages installed on disk? Do they have a main field? (we don't support exports yet)

Indeed all pkgs in SS are installed in disk except generate-ip and glob. The rest except node-clipboardy I can assure has main because I authored them

ljharb commented

Hmm. it is weird that https://unpkg.com/browse/@adamlui/minify.js@1.8.5/package.json doesn't specify dist in files, and yet the dist dir ends up published.

However I suspect this is a duplicate of #3107 (because it's exceedingly weird and rare to minify published packages).

Hmm. it is weird that https://unpkg.com/browse/@adamlui/minify.js@1.8.5/package.json doesn't specify dist in files, and yet the dist dir ends up published.

The dist files are in bin so probably npm picks it up from there, is this a potential reason for the bug?

However I suspect this is a duplicate of #3107 (because it's exceedingly weird and rare to minify published packages).

If you go browse npm on jsDelivr they're all minified, the reason I (and those minified pkgs) do it is to support reducing loadtime for CDN import in frontend env

ljharb commented

jsDelivr is a CDN, which is entirely different from npm (and using CDNs is no longer a good practice, for quite a long time now).

npm-installed things are consumed via a bundler, which would do the minification (and since it's doing it app-wide, will always do a better job than a package author is able to do).

jsDelivr is a CDN, which is entirely different from npm (and using CDNs is no longer a good practice, for quite a long time now).

I didn't say they're the same, I'm revealing why npm authors who use jsd to dist to frontend devs minify (it is best practice)

npm-installed things are consumed via a bundler, which would do the minification (and since it's doing it app-wide, will always do a better job than a package author is able to do).

Again, I serve not just node.js devs but also frontend ones, so I must minify for the former group to maintain my flexibility in one pkg (who will not be running npm)

ljharb commented

Minifying in an application is absolutely a best practice. Using third-party CDNs anywhere is not.

npm itself is how you distribute to frontend devs.

At any rate, even though nothing published on npm should be pre-minified, we should be supporting minified content, and that's what #3107 covers, so I'll close this.

Minifying in an application is absolutely a best practice. Using third-party CDNs anywhere is not.

If serving files over CDN, minifying all resources is best practice not just in an application. The requesters building sites want to reduce loadtime for optimal UX is the reason. JSD's most popular npm pkg https://www.jsdelivr.com/package/npm/bootstrap is minified for this reason

npm itself is how you distribute to frontend devs.

Indeed it is how I distrubte my files to frontend devs which I minify for the same reason other pkgs distributed to frontend devs using npm also dist/js/pkg.min.js (like above example with 13,000,000,000 monthly requests so IDK how can you speak as if CDNs are some no-no)

I reread and realized you thought I meant cdn was best practice, I meant when using cdn then minifying the resources is. I agree using cdn is risky actually.

Also I tend to not adhere to best practices (which are often suboptimal and grow dated) but instead explore what works best now for my own use case