How to develop libraries

[lkesteloot]

I have a library and an app that uses it:

app
    node_modules/library/...
library
    node_modules/...

The library is published in the NPM registry, and the app uses it from there. I use snowpack on the app, and all is great.

It's not clear to me what to do when I want to develop the library in the context of the app. The traditional NPM solution is to point to the local directory, either using a file: URL:

"library": "file:../library",

or using npm link. In both cases, changes to the library are not reflected in what snowpack serves when in dev mode. (It's fine in build mode.) I believe the problem is that snowpack caches the contents of a module using its version number, believing that if a subdirectory of node_modules claims to have a certain version number, then its contents are immutable. This isn't true when developing a local module.

I don't think the alias configuration will help here. It might point to the source within the library, but it won't help resolve the transitive dependencies of the library.

I think this question is related to these other discussions, but not exactly: #1464 #2534

Ideally snowpack would recognize that the library directory under the app is a link and not treat it as immutable. Another option is to not modify package.json and instead tell snowpack directly that this library should be found locally (and not treated as immutable). This would be extra helpful for transitive libraries that I'm developing (sub-directories of library also used by app).

Bonus points: This is all using TypeScript, and snowpack could recognize that the TS code of the library has changed and rebuild both the library and the main app. Not a big deal if this isn't possible, I can always tsc --watch the library.

BTW I was initially on webpack, and this use case failed there too, which is what led me to search for something better, and I found snowpack.

How do you all develop libraries and simultaneously test them from an app?

[Danzo7]

something definitely need to be fixed

[thedutchy]

Looks like this repository has exactly the example you need (at least it was exactly what I needed :-)):
https://github.com/edmulraney/snowpack-monorepo

The structure is as follows:

• components
• framework that uses components
• app that uses framework

No matter whether you change code in components, framework or app, the app instantly updates in the browser, completely without page refresh and whilst maintaining state. It's pretty amazing if you ask me.

[FredKSchott]

Support for this is going out soon! you can try it today with npm install snowpack@next. More info in #2707

[FredKSchott]

Ah yea, you'll run into trouble trying to get something building that is meant to use Node.js builtins. Snowpack's primarily focused on web development, so something like http2 can be shimmed/ignored, but will ultimately fail if ever used in the browser (for example, if you called something like createServer, since that API doesn't exist in the browser).

Can you share the import in question that you think is causing this? Is it just import 'firebase'? Would love to take a deeper look if this is for a library that's ultimately meant to run in the browser.

One other thing: the mount config may be useful if you haven't defined one yet. This makes sure that Snowpack is only building a subset of your directory, instead of the entire directory.

[lkesteloot]

My repo is here. The main Firebase imports are here. I think Firebase is intended to be used on both client and server, but certainly not just server. Maybe they need to break their library up a bit better? Also the current version of snowpack doesn't have this problem.

[FredKSchott]

Okay, I played around with your repo and your problem actually have an easy fix:

- import firebase from "firebase";
- import UpdateData = firebase.firestore.UpdateData;
+ import type firebase from "firebase";
+ type UpdateData = firebase.firestore.UpdateData;

import type tells your tools that the package itself doesn't need to be built, since you only need the type info. Our internal esbuild scanner is usually smart enough to catch this, but I bet the import UpdateData = firebase.firestore.UpdateData; line confused it.

With this change, you don't even need --polyfill-node!

[FredKSchott]

I was also to improve some of our polyfill handling based on trying to get it to work (2570f07).

[lkesteloot]

I didn't know about import type, and of course I don't know enough about snowpack to guess that was the problem, but it's great to lighten the imports anyway.

That worked, I was able to get the site up and running! Also, after adding this to my snowpack config:

workspaceRoot: "..",

I was able to do npm link trs80-emulator to use the local library, and everything magically refreshed when I saved a source file of the library from the IDE. (I also have a tsc --watch in the library.)

I think I'm all set! Thank you Fred! Let me know if you'd like me to write this up as a guide for the docs.