What is the right way to work with Parcel application and library when those are not in the same workspace?

[padcom]

Hello,

following a bit on discussion #8087 I am looking for a unified way of working with libraries. Normally, to link a dependency one would use npm link but it seems that Parcel has a different understanding of what to do when a package in node_modules is linked.

So here's the setup I'd like to use:

1. Have a library that is on the side and is being built with $ parcel watch
2. Have a project that has this library either $ npm linked or referenced using file:../my-lib, which usually works with other bundlers
3. When I make a change in the library, Parcel should rebuild that library (that's actually working pretty nicely!)
4. When the library has been updated the application should be rebuilt
5. The browser should do a full page reload (an external dependency has been changed, there's nothing else to do).

The last point does a refresh, but only if no symlinks are used (so won't work with the file:... protocol) and it's too weak, because the new code doesn't get included in the page until a manual full page reload. In the scenario where I'd manually create the package folder under node_modules in the final product and manually copy files from lib/dist to app/node_modules/lib/dist then the manual refresh works, but that is very inconvenient...

I'd like to know how to instruct Parcel to not resolve any symbolic links and just treat every folder and file as-is instead. Is that at all possible?

[rodrigo-nexudus]

Hey @padcom , did you get anywhere with this? I've run into the same issue, the refresh was working fine in parcel-bundler, but I've updated to parcel V2 and now changes in the library do not cause the main project to refresh. Incredibly frustrating when you're building a library and testing it on the fly in a separate project.

[mmontone]

Not ideal, but better than nothing: I run a watcher on the library. Then indicate Parcel to watch on the built library dist file using parcel Entries. Also use --no-cache option.

[padcom]

Guys, to be perfectly honest, I ditched Parcel a long time ago in favor of Vite. It just works so much better, not to mention faster and reliable. One of the killer features for library authors is the ability to contain and easily run a test application inside of the same projects - no more mono repos, full HMR, and (finally) a single configuration that is easy to maintain and share.

Check out my vite configs here: https://github.com/padcom/vite-config

It's so easy to use it's almost a crime:

1. install @padcom/vite-config-vue-lib
2. stick this into vite.config.mjs:

import { defineVueLibConfig } from '@padcom/vite-config-vue-lib'
import pkg from './package.json'

export default defineVueLibConfig(pkg)

3. create index.ts
4. create index.html
5. create vitest.setup.js

Done - you've got a test project and the library in one place. My config understands that "dependencies" and "peerDependencies" are transitive and should not be included in the final build so that takes care of all the externals. Easy!

Previously creating a library was a nightmare - now I do it for fun.

[padcom]

Oh! And if for whatever reason that feels like a lot of work...

npm create from-github padcom/vue-lib my-super-duper-library

That'll get you not only the above but also i18n, tailwind, autoprefixer... the whole 9 yards.

[rodrigo-nexudus]

Guys, to be perfectly honest, I ditched Parcel a long time ago in favor of Vite. It just works so much better, not to mention faster and reliable. One of the killer features for library authors is the ability to contain and easily run a test application inside of the same projects - no more mono repos, full HMR, and (finally) a single configuration that is easy to maintain and share.

Check out my vite configs here: https://github.com/padcom/vite-config

It's so easy to use it's almost a crime:

1. install @padcom/vite-config-vue-lib
2. stick this into vite.config.mjs:

import { defineVueLibConfig } from '@padcom/vite-config-vue-lib'
import pkg from './package.json'

export default defineVueLibConfig(pkg)

3. create index.ts
4. create index.html
5. create vitest.setup.js

Done - you've got a test project and the library in one place. My config understands that "dependencies" and "peerDependencies" are transitive and should not be included in the final build so that takes care of all the externals. Easy!

Previously creating a library was a nightmare - now I do it for fun.

Ended up doing exactly the same! We just use local dependencies from package.json directly, works great! It just became completely untenable to try and build smaller libraries for a project using Parcel. All major projects at company were changed to Vite and we haven't looked back.