Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option to disable bundling for building libraries #7254

Closed
silvenon opened this issue Nov 5, 2021 · 7 comments · Fixed by #9489
Closed

Option to disable bundling for building libraries #7254

silvenon opened this issue Nov 5, 2021 · 7 comments · Fixed by #9489

Comments

@silvenon
Copy link

silvenon commented Nov 5, 2021

Discussed in #6845

Originally posted by Thoud August 31, 2021
Hey everyone,

currently I'm trying to create a React component library which gets published to a registry and imported by another project.
My goal is to have a library which builds the source code in the same file structure as in src.

The idea behind this is that the project which imports the library has the possibility to only import a single component out of there instead of importing the whole thing. In addition to that it would be nice if the components (when importing each other) would not get bundled up into huge files with all their imported files but instead being build into individual files and only being referenced (just like node_modules but on a component level). Here a short example of what I mean:

Component B imports Component A and C.
All three files get compiled to individual files but instead of dumping the code from Component A and C into B and then compile Component B into a big file , it would be great if they would get compiled separately but in a way that component B references the other two, so that no code duplication occurs.

I hope that my explanation makes any sense, if not please let me know which parts are unclear and I will give my best to clarify them.
I'm happy for any help or hints to the solution :D

🙋 feature request

Add an option to disable bundling, only transpile. While I'm aware that this feature is very big, I still wanted to request it to hear your thoughts.

🤔 Expected Behavior

When building a library I expect running npx parcel build [input] only to compile source, not bundle it.

😯 Current Behavior

Parcel always bundles (with the exception of being able to exclude node modules).

💁 Possible Solution

Parcel could add a new option (e.g. --no-bundle) that could also be the enabled via package.json somehow, possibly as the default for libraries. This feature would also normalize glob inputs, so maybe Parcel could also start recognizing glob values for the source field:

"source": "./src/**/*.ts"

but I haven't thought it through.

🔦 Context

When building a library, bundling is unwanted, I want to compile the source files in the same structure as they are in the source directory.

@devongovett
Copy link
Member

Thanks for opening this. I think we should support this. It will require a different bundling strategy (i.e. 1:1). Luckily it should be possible in Parcel's architecture since bundlers are plugins. We're currently reworking the API a bit, but no reason it won't be possible soon.

@AlexVipond
Copy link

I'd love have this feature!

For context, I'm working on an app where most of the frontend codebase is in untranspiled JS files that declare variables and functions in the global scope. The short-term goal is to run each file through Parcel for transpilation and minification, but not bundling, because we need to keep code in the global scope (not inside IIFEs) for now.

The longer term strategy is to migrate to modules, using Parcel to properly bundle everything and support TypeScript, but the need for just transpilation and minification is more immediate.

@steve-taylor
Copy link

steve-taylor commented Nov 24, 2022

This should be the default for libraries if isLibrary && outputFormat !== 'global'. The only reason to bundle a library is for consumption via a script tag.

However, I note that Parcel automatically excludes node_modules from bundling in library mode, so there doesn't seem to be any harm in it. (I'm not sure what other bundlers do. I would hope they also automatically exclude node_modules.)

https://www.briefs.fm/3-minutes-with-kent/221

@devongovett
Copy link
Member

The default for building libraries in Parcel does not include dependencies from node_modules, only your own code.

@steve-taylor
Copy link

The default for building libraries in Parcel does not include dependencies from node_modules, only your own code.

Yeah, I updated the comment after reading the docs again. (Forgot to save the edit earlier 😂)

@snowyu
Copy link

snowyu commented Mar 13, 2023

Still bundle together even isLibrary: true

parcel build src/**/*.js

  "main": "dist/cjs/index.js",
  "module": "dist/esm/index.mjs",
  "targets": {
    "default": {
      "outputFormat": "commonjs",
      "isLibrary": true
    },
    "main": {
      "includeNodeModules": false,
      "distDir": "dist/cjs",
      "outputFormat": "commonjs"
    },
    "module": {
      "includeNodeModules": false,
      "distDir": "dist/esm",
      "outputFormat": "esmodule"
    }
  },

@johnpyp
Copy link

johnpyp commented Apr 8, 2024

@devongovett I tried the new bundler-library plugin, and a few things so far are unintuitive.

  • There are no docs yet afaict (new feature :) )

  • I was expecting, being unfamiliar with how parcel actually works, an output similar to just running tsc on my src folder, maybe pruning files or functions that weren't used. Instead, I got individual js files for every file, but critically only got a single .d.ts file and a single .cjs file. Is this intended? Is there a mode more comparable to tsc?

For reference of another project, https://github.com/unjs/unbuild takes this approach of basically emitting every file to the dist with multiple variants based on your exports.

I could be convinced that maybe I shouldn't want this, but currently what I want is .d.ts files for each file, and maybe even associated .cjs files, for every file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants