Option to disable resolve.conditionNames check

[mon]

The documentation states:

If you're using Svelte components installed from npm, you should specify this option

I don't use any external Svelte components, and this explodes my webpack build output with errors from both Svelte and zip-js that look like:

Module not found: Error: Package path . is not exported from package C:\...\node_modules\svelte (see exports field in C:\...\node_modules\svelte\package.json)

Adding the fullySpecified: false check for svelte as mentioned in the README seems to solve the svelte errors, but I can't work out the right syntax to fix zip-js, so I'd just like to disable the warning entirely.

[dehmer]

Same problem here with OpenLayers.
Build is OK without resolve.conditionNames: ['svelte'] and currently I also do not use external Svelte components.
But what if we were to use external components?

I don't really understand how path aliases work and how this may interfere with OpenLayers (and other libraries), but for me this seems like a more involved problem to address.

If it helps, I can create a repo to reproduce this. Please let me know.

ERROR in ./node_modules/ol/layer/MapboxVector.js 9:0-60
Module not found: Error: Package path . is not exported from package /Users/dehmer/Development/bitbang.io/templates/9ec34c56/node_modules/ol-mapbox-style (see exports field in /Users/dehmer/Development/bitbang.io/templates/9ec34c56/node_modules/ol-mapbox-style/package.json)
 @ ./node_modules/ol/layer.js 10:0-64 10:0-64
 @ ./src/Map.svelte 15:0-45
 @ ./src/App.svelte 19:0-31 26:11-14
 @ ./src/main.js 3:0-31 5:16-19

ERROR in ./node_modules/ol/source/GeoTIFF.js 6:0-12:17
Module not found: Error: Package path . is not exported from package /Users/dehmer/Development/bitbang.io/templates/9ec34c56/node_modules/geotiff (see exports field in /Users/dehmer/Development/bitbang.io/templates/9ec34c56/node_modules/geotiff/package.json)
 @ ./node_modules/ol/source.js 12:0-55 12:0-55
 @ ./src/Map.svelte 14:0-32
 @ ./src/App.svelte 19:0-31 26:11-14
 @ ./src/main.js 3:0-31 5:16-19

[giamir]

@dummdidumm We do have a similar issues with this check in my project.
I have noticed 2 problems:

• Checking if conditionNames is set by reading the file as a string ignores any potential configuration imported from separate files (e.g. webpack.common.ts)
• My experience authoring webpack loaders is limited but I believe it would be better to add the check as a webpack warning (example) instead of using console.warn. Webpack ignoreWarnings field doesn't have any effects on console.warn.

I also notice that at least for configuration files written in TS this conditional return false even if the configuration is a function:

typeof config // { default: [Function (anonymous)] }

Thanks for your support.

[morpheus7CS]

Hey @dummdidumm,

I'm having a similar issue with our package that provides basic support for Svelte compilation in Laravel Mix.

Since many of our users have requested it, we have added support for svelte-loader, so that the end users can extend the configuration without us having to support a large API surface area.

This is the issue that got opened a few weeks back:
wewowweb/laravel-mix-svelte#31

The compilation itself doesn't fail, yet the warning is displayed, even though the configuration passed on by the user is correctly applied to the file. (thanks again @alesvaupotic for source-diving the configuration)

So far, the issue identified by @giamir seems to be the culprit for it, namely bullet point one:

• Checking if conditionNames is set by reading the file as a string ignores any potential configuration imported from separate files (e.g. webpack.common.ts)

Thanks,
g

[farfromrefug]

Same issue here. I think the issue is that requiring our wepback.config.js wont work like that because we run it within a special environment (Nativescript).
@dummdidumm :

• wouldn't there be a better way to check for conditionNames? As a loader dont you have access to it directly? Seems weird to have to do that by require
• otherwise i think a way of disabling the check would solve it for most of us

[codegain]

I had the same error with these packages after adding svelte to conditionNames:

 error  in ./node_modules/sanitize-html/index.js                                                                                                1:38:35 PM

Module not found: Error: Package path . is not exported from package ./node_modules/htmlparser2 (see exports field in ./node_modules/htmlparser2/package.json)

 error  in ./node_modules/sanitize-html/index.js                                                                                                1:38:35 PM

Module not found: Error: Package path . is not exported from package ./node_modules/is-plain-object (see exports field in ./node_modules/is-plain-object/package.json)

 error  in ./node_modules/sanitize-html/index.js                                                                                                1:38:35 PM

Module not found: Error: Package path . is not exported from package ./node_modules/postcss (see exports field in ./node_modules/postcss/package.json)

and I'm using Symfony Encore to build my webpack.config.js file.
Instead of adding only svelte to conditionNames, I also added browser and import which is only mentioned in the README under "Usage" in the full configuration (the array was not set before):

conditionNames: [ 'svelte', 'browser', 'import' ]

and now the warning + the 3 errors are gone. Maybe this helps someone.

EDIT: It seems like conditionNames: [ 'svelte', 'import' ] is enough in my case.

[non25]

Hit this issue too. Here's the solution. 🙂

[morpheus7CS]

@non25 thanks a lot!

@codegain does this solve it?

Kind regards,
g

[codegain]

@morpheus7CS Sorry for the late response. Configuring it like

    mainFields: ['svelte', 'browser', '...'],
    conditionNames: ['svelte', 'browser', '...'],

solves the issues. For a quick test I reverted back to ['svelte', 'browser'] and it spit out errors again - so the updated docs work now.

[mon]

I re-attempted my dependencies upgrade today and hit the same issue - it took me a moment to realise that '...' was literal dots and not "the rest of your existing configuration" 😅

Everything works fine now so I'm closing this issue.