-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
[Feature] Use html as start point for bundling #31
Comments
Just realized I haven't commented on this yet. I think this could be a cool feature, but I assume that most people who want to do this would also need CSS bundling to work too. So I'm considering this as being blocked by #20. |
I think it can be achieved by parsing html file and finding a script tag. And then using it as an input file, so: esbuild < input.js and <script src="index.js"></script> might work the same. probably it is better to write a custom loader for it? I know that the feature is blocked by CSS bundling but I had some thoughts about implementing the feature of html as input file |
but there could be more script files, and also inlined scripts. |
well, in that case, we could collect all of the scripts and parse inline scripts the same way as |
+1 for this use-case. To give some context: Snowpack's new built-in optimize/bundle step is internally powered by esbuild. Snowpack supports HTML files as bundle entrypoints by scanning them for all script tags and then passing those JS files to esbuild as the entrypoints to bundle. For this to work properly, inline scripts have to be extracted into separate files and then linlined back in at the end. Hashed entrypoint filenames will introduce some additional relinking work for remote scripts as well. This workaround is workable, but it would be great if everyone didn't need to do this, and esbuild could handle this use-case either natively or via plugin. |
Can we not use esbuild's transform API as opposed to build API for this use case? Just FYI, I was playing around with this a little with https://github.com/osdevisnot/sorvor |
One big thing I really like about parcel is I can do The html file could be something like <!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<link rel="shortcut icon" href="favicon.ico" />
<title>A HTML Page</title>
<script src="./src/index.tsx" defer></script>
</head>
<body class="bg-gray-100">
<div id="root"></div>
</body>
</html> Parcel is smart enough to know favicon.ico needs to be copied, import React from 'react';
import {render} from 'react-dom';
import {App} from './App';
import './App.scss';
render(<App />, document.getElementById('root')); and outputted as <!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="shortcut icon" href="favicon.ico">
<title>A HTML Page</title>
<script src="app.js" defer></script>
<link rel="stylesheet" href="app.css">
</head>
<body class="bg-gray-100">
<div id="root"></div>
</body>
</html> Directory structure of
esbuild doing simple html parsing into entrypoints would really make it extra nice. 95% of SPA projects could really be simplified with something like this I'm happy to proof-of-concept this out in a PR. @evanw do you think you'd accept such a direction ? |
Hello! We just released a plugin for esbuild that handles html files as entry point, you can find it here. It's still a work in progress but a if you would try it, any feedback is welcome! Feel free to file any issue too! |
One important aspect of pointing Parcel to an |
@Prinzhorn You’re on the money. This is definitely one of the features I’m most looking forward to. Second would be CSS tree-shaking (not even sure how that would get implemented), but HTML entry points would be amazing. |
If we talk about the same thing, this is the oldest open issue of Webpack |
given that there's @edoardocavazza's plugin that does this, does it still make sense to have this issue here? |
the main benefit would be for those of us who only use the command line, for which the plugin api isn't available |
Additionally, the plugin mentioned above by @edoardocavazza (https://www.npmjs.com/package/@chialab/esbuild-plugin-html) is limited to a single html entrypoint. If esbuild supports html entrypoints, I hope it doesn't special-case that into "a single html entrypoint." That limits its usefulness to purely-single-page apps (vs multiple rich, bundled pages). |
@evanw |
the plugin from @edoardocavazza needs some fixes and then it can support multiple entry points. I've hacked it together myself and opened an incident to ask for a cleaner solution: chialab/rna#128 |
Parcel didn't work out well for me, also, the server hadn't been reloading when I was making changes, which was the main reason why I was trying it out. It didn't seem as stable as I hoped. @edoardocavazza's plugin is now very advanced and definitely an interesting reference for writing esbuild plugins in general. It doesn't fit my needs because it's doing too much, so I'm using it as a reference to write my own project-specific HTML plugin that will do only what I need. But it's quite confusing, the plugin needs to run a separate build for detected assets, which should then be rebuilt on each change, and somehow also cause the development server to reload… Challenging, but hopefully I'll get there one day. |
@jogibear9988 Hi, you mean html-bundler-webpack-plugin can also apply into esbuild config? |
no, sorry. It was an example how it works in webpack via the plugin. |
|
Not that I'm aware of, but you can hack your own. I used chokidar to watch the HTML file and trigger esbuild to rebuild. |
Actually, |
The HTML entry point should also support import maps. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script/type/importmap index.html <!doctype html>
<html lang="en" dir="ltr">
<head>
<meta charset="utf-8" />
<meta name="description" content="import map support" />
<title>import map support</title>
<meta name="viewport" content="width=device-width,initial-scale=1" />
<script type="importmap">
{
"imports": {
"lib": "/j/lib.mjs",
}
}
</script>
<link
rel="modulepreload"
href="j/app.mjs"
as="script"
crossorigin="anonymous"
/>
<link
rel="icon"
href="data:image/x-icon;base64,"
type="image/x-icon"
sizes="any"
/>
</head>
<body>
<main>
<h1>import map support</h1>
</main>
<script type="module" src="j/app.mjs"></script>
</body>
</html> j/app.mjs import { test } from 'lib'
test(); j/lib.mjs export test = () => console.log('test'); |
Would this be possible?
So that also both script tag types are supported (type=module and standard globals ones)
The text was updated successfully, but these errors were encountered: