Bundle passing the source code

[oscarotero]

Hi, thanks for this awesome project.

transform allows to set the source code but bundle only works by setting a filename. I need to bundle a css code passing the source code. Do you have plans to implementing that?

[devongovett]

It's not possible because we need to read the dependencies (i.e. @import) from the file system. I thought about a way for the JS API to pass a function callback to retrieve the contents of dependencies when needed, but this would significantly slow things down. What's your use case for this?

[oscarotero]

My use case is this plugin for Lume (a static site generator for Deno): https://github.com/lumeland/lume/blob/master/plugins/parcel_css.ts

The plugin gets the content of the css files, process the code and update the content. I don't mind parcel-css reads the dependencies from the file system, but I'd like to set the code of the main file (the entry point).

There are other similar plugins for Lume that works in the same way:

• postcss: https://github.com/lumeland/lume/blob/master/plugins/postcss.ts
• sass: https://github.com/lumeland/lume/blob/master/plugins/sass.ts

In these two cases, the plugin reads the content of the loaded files, process the code and inlines the imported dependencies from the file system. The dependencies are resolved related to the main file path or providing a list of paths.

[devongovett]

Well another problem for Deno is that the WASM build doesn't have bundle at all because WASM doesn't have filesystem access. I'm not sure if there is a way to solve that.

[oscarotero]

Ah, I didn't know that.
I'm not familiarized with Rust + WASM, but for SASS, I'm using denosass that is WASM and has access to the file system, I don't know if this helps.

Your idea of providing a JS API to read files and retrieve the content looks good too, and maybe it's the most flexible.

Another idea is providing a set of sources, in the same way Deno.emit() does (https://doc.deno.land/deno/unstable/~/Deno.EmitOptions) but this does not fix the entire problem because you need to know the sources before.

[yisar]

I think this is a very common requirement, or you can provide a rust plugin to do this.
Because I think for parcel-css, adding as many fetures as possible is a good direction.
Especially some fetures that are not standard but very commonly used, such as @import，rpx

[petergoes]

I would like this feature as well. My use case: bundle all css files in a design system dynamically.
I have a folder of components where each component has its own folder with a dedicated css file. In a build script I collect all css file paths. I do something like this (the array is generated with fs)

const csscode = [
  'components/button/button.css',
  'components/header/header.css'
  ...
]
.map(path => `@import './${path}';`)
.join('\n')

This gives me a 'virtual' css file with only import statements that I want to bundle.

This way:

• team mates do not forget to add css files
• The file structure is the single source of truth just like the routes in the routes folder (like remix_run, nuxt and next)

[devongovett]

Should be possible in the next version by implementing a custom resolver: #263. See the bundleAsync example in the readme: https://github.com/parcel-bundler/parcel-css#from-node

[oscarotero]

Oh, that's awesome!
I'm looking forward to the next version.
Thank you