Compatibility for projects without index.html

[klausbreyer]

first of all: it's great that this project exists!
i use parcel to compile and bundle pure js. then the goodie bag doesn't kick pure ...

do you have a workaround for me how to use dsa anyway?

[edm00se]

Thanks! I'm glad you found it as able to fill a need.

Do you have an example you could point me to? I've not done much with pure js, which looks to be a js based templating engine, which likely means a couple of things about why it isn't likely working "out of the box".

I'm guessing that the implementation of parcel as you're describing it is not directly talking to an index.html, which this plugin currently targets exclusively. That said, if it would be useful, I'm all for configuring this plugin, with certain defaults, to accommodate for other situations.

[klausbreyer]

No, i am not talking of some framework. Sorry for the confusion.

I am just building simple plain javascript with parcel.
parcel build src/studio.js

I have trouble with ie11 because of fetch and promise and currently looking for some fix I can include into my project.

But as I understand, your fix needs to adjust the .html file. is this correct?

[edm00se]

Aha I see, more vanilla js than "pure js", as you're performing an arbitrary js bundle build, which means this plugin isn't detecting the index.html being processed by parcel; because it has no visibility. Okay, that clears that up.

Is there a particular reason you're not using your index.html as the entry point? Parcel will minify html and add some other nice features making more useful beyond just a different bundler, but also add in a development server with live-reload, and more.

We could potentially configure this plugin to handle other entry points (such as a js only build), but as there wouldn't be something distinguishing that from a non-browser js bundle, such as for node.js, it could get more complicated pretty quickly. Parcel's approach is to only apply browser based concerns for entry points that are html, so I'm inclined to keep consistent with that.

To address your immediate situation, you could manually generate the polyfill file. The steps to take would be:

• create a new file, likely adjacent to your bundle.js output location, to contain your two polyfills
• add in the contents, in order, for:
  • es6-promise (the source from unpkg: https://unpkg.com/es6-promise@4.2.8/dist/es6-promise.auto.min.js)
  • unfetch as I used in this plugin (the source from unpkg: https://unpkg.com/unfetch@4.1.0/polyfill/index.js)
• save it and add it as a script before your bundle.js

If you want to be a nice lazy developer, you could view a copy of the built version of the "goodie bag" "in the wild" here:
https://edm00se.codes/modernize-ng1/goodie-bag.min.js

A note on unfetch, as a package is mostly compatible with the true fetch API requirements, but lacks somewhat in specific, less frequent, requirements; the trade off is ~500kB for the file. If you need more features, check out GitHub's fetch polyfil, whatwg-fetch.

[edm00se]

After thinking about this for a little while, I'm not sure a non-html bundled package is a usage path I want to support as part of this plugin. This could change in the future, but the steps to take to achieve the same are well documented in the above comment and have been called out in the usage paragraph in the readme.