Replies: 1 comment 1 reply
-
Yea, I think it's fair that |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
So, I'm trying out a slightly crazy experiment: using Snowpack to build my Node server-side app, along with the client. This makes (some) sense since I have a fair bit of isomorphic code and a build with a lot of extra transforms and plugins, so sharing the configuration saves the work of maintaining a separate build toolset. I've had some early success by using Node's experimental module loader hooks to fetch code directly from Snowpack's server.
One issue that I haven't entirely figured out yet is how to deal with imports of Node's built-in packages. My loader hooks detect those and deal with them directly so I'd like Snowpack to just ignore them altogether. I added the built-ins to the
installOptions.externalPackage
list, which got them through the install step, but when fetching app modules that import built-ins Snowpack still complains that, e.g.,Import "fs" could not be resolved
. Everything still works (!) but the warnings get quite messy and can easily hide true positives.Would it make sense for Snowpack's import resolver to respect the
installOptions.externalPackage
list? (That option appears to be undocumented so it's not clear to me what the intended semantics are.) If not, perhaps there's some other way to get Snowpack to ignore the built-ins? I realize that my use case is way out there and don't expect any major changes to Snowpack to accommodate it but I'm hoping there's some unobtrusive way to shoehorn it in -- I'm so close!Thanks.
Beta Was this translation helpful? Give feedback.
All reactions