Parcel: Copy all files from a predefined folder into the dist folder

[samuelgozi]

🙋 feature request

I've seen some other feature request that has a similar idea, but in different ways, and other requests that might be solved by using a feature like this one.

I would like to have the ability to include files in the build process without requiring them in code.
This is very useful and also results in better-looking output, and easier for cache management, especially in service workers(arguably), but anyways its much better to have an idea of the final file/folder structure of the project.

Also, I think that its better to handle some files that way than letting Parcel treat them differently than the other files, like for example the SW(in some cases), or if you need to dynamically import images from a folder, and you can't know ahead of time the names of the files.

This feature can help with #301 and #557

🤔 Expected Behavior

All the files within the folder called(for example) assets will be copied as is, and without change into the dist folder.

src/
    assets/
        images/
            logo.svg
            ios-image.png
            whatever.png
    sw.js
    some-other-file.json
main.js
index.html

will be copied to the root of the dist folder:

dist/
    index.hash234234.html
    main.hash34-0294-0.js
    images/
        all the image files
    sw.js
    some-other-file.json

😯 Current Behavior

Only files required inside the bundle are copied to the dist folder and you have to know the names of all of them beforehand and have them beforehand.

💁 Possible Solution

It's a pretty simple feature, so I would say that there are two ways of implementing this.

1. letting the user decide the name of the folder and then specify it in the command line.
2. have a convention for the folder name. either way, the user will have to adapt.

🔦 Context

1. Mostly, but not only. I think that this feature will help me and other migrate into Parcel and keep most of the old structure of the project the same.
2. Dynamically import files without knowing their name(its way more common than you think).
3. Easier and cleaner dist structure(which can help when working with other technologies/serverside etc).
4. Not needing to wait for Parcel to handle a new convention the right way(it happened with service workers, and we still don't get it right).

[danielo515]

So there is no current way on parcel to just copy some files, right ?

[DeMoorJasper]

Not sure why this is such a requested feature.
You could just create a command that includes a copy.
There is no way to do this without including config that is probably longer than the command...

cp -R ./src ./dst && parcel build ....

In practise parcel wouldn't probably be the only command you run on a build anyways.

However the original issue doesn't seem to be about copying it's more about naming?

[paulcsmith]

That works on initial build, but won't do anything when you add files after parcel starts. You'd have add your own watch task to do it. Definitely possible to do, but not as convenient

[danielo515]

My concern will be probably more about entry points than just copying files.
I could have several files (ej: index.html and login.html) that I want to be bundled and processed by parcel, but seems that I have to just choose one.

[DeMoorJasper]

@danielo515 this https://en.parceljs.org/getting_started.html#multiple-entry-files ?

[danielo515]

Thanks!

[j0hnm4r5]

I have a real use-case for this — we are using model loaders in Three.js.

Just using Three.js is already a good use-case: copying over the "examples" folder (which is more of a set of required plugins than examples) is almost mandatory since Three doesn't use imports consistently, instead relying on a single global THREE namespace and individual side effects within loaded examples/plugins to add themselves to that namespace. In order to use them with Parcel, you have to copy over each example/plugin, convert them to use imports and exports, and them import them as normal within your code.

That's all doable, and is more of a problem with Three.js than it is with Parcel however, so it's not too big of a deal. The big issue is when importing files like GLTFs.

GLTFs are 3D models that consist of two separate files: a .gltf and a .bin. The .bin is referenced as a exact URI from within the .gltf, which is obviously not JS, so it can't use import to dynamically update the reference whenever Parcel rebuilds. This means that GLTFs are completely unusable as-is.

[etoxin]

i'm using this with my three js project
https://www.npmjs.com/package/parcel-plugin-asset-copier

[j0hnm4r5]

I ended up using https://www.npmjs.com/package/parcel-plugin-static-files-copy with a few modifications (the original doesn’t handle bundles with multiple entry files at all).

[mrozekma]

You could just create a command that includes a copy.

cp -R ./src ./dst && parcel build ....

All the people trying to build the project on Windows would be thrilled by that

[Defite]

Not sure why this is such a requested feature.
You could just create a command that includes a copy.
There is no way to do this without including config that is probably longer than the command...

cp -R ./src ./dst && parcel build ....

In practise parcel wouldn't probably be the only command you run on a build anyways.

However the original issue doesn't seem to be about copying it's more about naming?

This is not working without entry file. Very bad.

[Defite]

I ended up using https://www.npmjs.com/package/parcel-plugin-static-files-copy with a few modifications (the original doesn’t handle bundles with multiple entry files at all).

not working as well.

[mathieu-pousse]

@DeMoorJasper I definitely agree with you that is probably not the concern of parceljs to copy static files when building the distribution, but how to prepare that files when running parcel serve ?

BTW, parcel-plugin-static-files-copy works fine ! :ok_hand: :tada:

[felipemullen]

I'm not sure why there is so much resistance about copying assets. I am not trying to be critical, it's just an observation.

I ran into this when trying to access raw mp3 files that are supposed to be accessed by howler.js. I couldn't use a require statement since it expects a path and not a Glob, and for that reason files were never copied to the output folder.

Anyway, I used parcel-plugin-static-files-copy and it solved my problem.

[niamleeson]

parcel-plugin-static-files-copy for me did not work at all for gltf files. I received unhandled promise rejection saying the path is undefined.

The one @etoxin posted worked flawlessly.
https://www.npmjs.com/package/parcel-plugin-asset-copier

[thedamon]

I also find it weird not to support a static folder by default. There's just such a variety of very different reasons to want to be able to predict the location of a group of static files and just being able to have a static folder that gets preserved on build with the same relative path would solve all those problems.

This plugin looks nice, but I'm currently not able to access the files on the localhost dev server, if something is in src/assets/icons/whatever should it be at localhost:1234/assets/icons/whatever ?

I'm currently trying to figure out how to link to a file for a favicon that's set dynamically by vue-meta based on a computed property.. and I just can't.. have a bunch of icons in assets/icons/*.png.. and can't seem to get access to them.

I have this:

metaInfo(){
    return {
      link: [
        {rel: 'icon', type:'image/png', href:`./assets/icons/${this.favicon}.png`}
      ]
    }
  },

but i don't really know how to 'tell' parcel that all the files in this directory are needed.

If there was a sort of static folder that persisted between dev and dist (common pattern in a lot of site generators) i imagine it'd just work.

[pie6k]

My use case is for social media images. Eg.

<meta name="twitter:image" content="./assets/cover.jpg" />

It will resolve to correct path, however, twitter (and FB) crawlers require full URL to be present here (starting with http(s).

[manniepack]

I would like to +1 this request. I have yet to try any of the plugins mentioned (but I will soon!), but my use case for this was spritesheets and Pixi.js.

Pixi.js is a 2D rendering engine, with a Loader type which loads assets during runtime using paths. I managed to get the static images working easily by doing a path import of my image assets, i.e.:

import spritePath from '~assets/sprite.png'

and then passing the path:

PIXI.Loader.shared
  .add('sprite', spritePath)
  .load(callback);

However, like @j0hnm4r5 ' use-case, the same didn't work for *.json spritesheet files. Each spritesheet excepts to find certain assets relative to itself. On top of that, Parcel only supports importing JSON files as data and DOESN'T return runtime paths. So even if Pixi.js could find the JSON files properly, the spritesheets would still not locate their required assets.

Thanks for the Parcel plugin recommendations! I can see it has been iffy getting either of the plugins working for some users here, but I hope I luck out.

[msandrini]

This is a feature that would add almost no complexity to Parcel's CLI and would be, probably, easy to implement, so I see a nice cost-benefit from implementing it. I get the reason why the maintainer thinks this is not so useful of a feature, as we all should be very comfortable with moving files around when needed. To me, though, it is clear that it would be a convenience feature, what doesn't sound too important but collides with the fact that Parcel.js itself is a huge convenience library that people use so they don't have to do things by hand.

[arvindamirtaa]

I just want to add that this will cover one more base for running parcel in a CI environment.

[kgrigorian]

yes please

[Derryrover]

Yep please add this.
Parcel is an awesome bundler.
But I am just a simple frontender.
Having to ad "cp -R ./src ./dist &&" to my package.json makes me nervous.

[danielo515]

What does people have against the mentioned plugins?

[Derryrover]

What does people have against the mentioned plugins?

Nothing in particular against plugins or command lines.
It is just that it would be so much nicer without.
Just making it work "as is", since it seems it is a often needed feature.

[fregante]

What does people have against the mentioned plugins?

They don't work with Parcel 2.

I think the easiest way for Parcel to support this is to specify a _"no-transform transform"_ for unsupported filetypes, so that if I run parcel build image.png (example), parcel just "transforms" the file and places it in the dist folder.

Solution for Parcel 2

And… good news! It exists:

// in your .parcelrc
{
  extends: ['@parcel/config-default'],
  transformers: {
    '*.png': ['@parcel/transformer-raw']
  }
}

parcel build 'images/*'