Skip to content
This repository has been archived by the owner on Apr 21, 2022. It is now read-only.

[Plugin Request] base64 file require plugin #47

Open
benwiley4000 opened this issue Apr 28, 2019 · 5 comments
Open

[Plugin Request] base64 file require plugin #47

benwiley4000 opened this issue Apr 28, 2019 · 5 comments

Comments

@benwiley4000
Copy link

benwiley4000 commented Apr 28, 2019

My use case is that I have a package where a bunch of PNG image files are required in my code like const image = require('./image.png');. This works fine for my example app which is built using Parcel. This works less fine for someone just using regular JavaScript, so part of my current build step is that in the target lib/ directory, all the png files are replaced with base64 data url exports with .png.js file extensions, which means we can use the exact same require statement and it's now legal JavaScript.

I think it would be great to have a plugin that does this sort of thing for pikapkg. It would work similarly to Webpack's url-loader which requires files from the file system as base64 data urls.

Good options to have:

  • Max file size before falling back to the asset plugin (alternatively, there should be an option for no limit, which makes sense for my use case... not sure which should be default).
  • Mimetype map - we can set some defaults for common file types, but generally we should be able to map arbitrary extensions or regexes to mimetypes in our configuration

I'd be happy to work on this myself. However...

Disclaimer

I don't know how to build a pikapkg plugin, and there's no docs on that yet, so I'll need help! 🙂 Thanks!

@benwiley4000
Copy link
Author

I think it's important that all this plugin does on its own is replace the png file with a js module containing its data; a search/replace of png require statements with data urls would mean potentially duplicating asset data unnecessarily.

@benwiley4000
Copy link
Author

Hm, seems like https://github.com/rollup/rollup-plugin-url would handle this pretty easily.

The thing is, it seems like several of the different plugins would need to be aware of the specified configuration for data url imports. Is there any concept of a shared rollup config across multiple plugins?

@FredKSchott
Copy link
Owner

FredKSchott commented May 2, 2019

Thanks for filing this! I love this idea, I've been punting on what happens to non-js assets for too long now, it would be great to take a more serious look at this.

A few thoughts:

  • Right now we don't really have an idea of sharing config across plugins, but we do have an idea of a common shared "assets/" directory. Check out https://github.com/pikapkg/builders/tree/master/packages/plugin-copy-assets which basically just copies assets/ -> pkg/assets, and all relative imports from the src/ directory continue to work.
  • Could this same idea work for the proposal above? A new plugin to use instead of plugin-copy-assets, but in the process of copying the assets folder it actually converts each file into base64-encoded js files similar to how you describe above?
  • This has the added benefit of all builds sharing the same static base64 assets, so that they aren't duplicated inside of each "distribution".
  • One tricky bit of it: it would also need to rewrite the imports inside of the main dist-src/ directory to point to the new asset file names with the added .js file extension.

Does that make sense? Any thoughts? Would love your help on this if you have the time! Also If you are interested, I'd love to make this an official plugin given how essential it is for the projects importing non-js assets in their js.

Happy to help with this as well, The first thing I'd recommend doing is just checking out the other build plugins in this repo. Each one exports some number of "lifecycle hooks" that @pika/pack will call at different times during the build process.

@benwiley4000
Copy link
Author

Thanks for all the thoughts!

I can see the ostensible benefit of externalizing asset files, although I am aiming for a single-file distribution in my case.

@FredKSchott FredKSchott changed the title base64 file require plugin [Plugin Request] base64 file require plugin Jan 16, 2020
@lkraav
Copy link

lkraav commented Jun 18, 2020

I'm also trying to overcome importing HTML files, where pack chokes

Error: Unexpected token (Note that you need plugins to import files that are not JavaScript)
    at error (/home/leho/Documents/web-components/aybolit-conversionxl/node_modules/rollup/dist/shared/node-entry.js:5400:30)
    at Module.error (/home/leho/Documents/web-components/aybolit-conversionxl/node_modules/rollup/dist/shared/node-entry.js:9824:16)
    at tryParse (/home/leho/Documents/web-components/aybolit-conversionxl/node_modules/rollup/dist/shared/node-entry.js:9717:23)
    at Module.setSource (/home/leho/Documents/web-components/aybolit-conversionxl/node_modules/rollup/dist/shared/node-entry.js:10080:33)
    at /home/leho/Documents/web-components/aybolit-conversionxl/node_modules/rollup/dist/shared/node-entry.js:12366:20
    at async Promise.all (index 7)
    at async Promise.all (index 2)
    at async Promise.all (index 3)
    at async Promise.all (index 0)
    at async Promise.all (index 0)
Error: Command failed with exit code 1 (EPERM): npx pika-pack

I would've expected a rollup.config.js like

import html from 'rollup-plugin-html';

export default {
  plugins: [
    html()
  ]
}

to Just Work ™️ but apparently it's not that simple, as rollup() API call seems to ignore config files.

Thanks for filing this! I love this idea, I've been punting on what happens to non-js assets for too long now, it would be great to take a more serious look at this.

Am I in the right place with this? Seems like it ⬆️

EDIT

I found one recent example of implementing rollup plugin configuration https://github.com/atomicpages/pika-plugin-build-web seems like what I'd want?

lkraav added a commit to conversionxl/aybolit that referenced this issue Jun 18, 2020
saas786 pushed a commit to conversionxl/aybolit that referenced this issue Jan 23, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants