Comments (9)
Microbundle is a tool for building libraries, not apps. So again, wrong layer as this should be implemented in the tools that consume Microbundle's output.
Also, I don't think opening these copy/pasted issues everywhere is going to get you the desired reaction.
from microbundle.
Do you have a preference for how I implement this? Should it be a default on, and/or added as a new configurable option, etc?
Sorry, meant to say that enabling it is fine, no need for config.
I don't love that package maintainers will need to tell their consumers that they'll have to alter their browser's settings if they want the old behavior (as this seems to be enabled by default in Chrome), but we have too many flags here as-is, IMO.
I don't open issues to 'demand'; I raise a thing (bug, feature, etc) that I think would benefit the project, as an invitation to a conversation/collaboration around the thing being raised.
I often don't want to jump straight to a PR before there has been at least some level of "yes, sounds good" from a project; as it's not worth sinking my time/energy
I get that, but unfortunately collaboration like this demands a time investment from someone: either the (potential) contributor doing work up front or the maintainers fielding questions. I know it seems like a quick thing but many of us have another 50+ repos we're fielding questions in (and even more that we're neglecting) on top of work, personal life, etc.
But again, that's just me. Opening issues for discussion/one-offs are a-okay, but if you're trying to standardize an entire ecosystem, personally, it comes off a lot more positive if you're making some initial investment to make that happen. A hacky, post-build injection in Preact's source maps (for this issue) would've been a fine starting point, for example.
from microbundle.
Microbundle is a tool for building libraries, not apps. So again, wrong layer as this should be implemented in the tools that consume Microbundle's output.
@rschristian This context from the other thread that explains why I opened it here:
Fair enough. Well you may or may not find this issue relevant there then, since it's a bundler (though I'm not really sure how a thing like this that should be configurable would be exposed through a 'no config' tool):
Originally posted by @0xdevalias in preactjs/preact#4225 (comment)
Also, I don't think opening these copy/pasted issues everywhere is going to get you the desired reaction.
@rschristian I'm not sure what you're assuming my 'desired reaction' is here. I'm trying to get a useful feature implemented across the major web frameworks. It's copy pasted because there is no point individually re-writing the same context and details every time since it will be exactly the same. They are cross-linked so that it's easier to find the requests, any relevant comments/context, and implementation specifics between the frameworks to reduce the effort of having to 'start from scratch' for each.
from microbundle.
This context from the other thread that explains why I opened it here:
Fair enough. Well you may or may not find this issue relevant there then, since it's a bundler
Per the tag line, this is a tool for modules, not apps.
I get why you opened it but, like Preact's repo, it doesn't fit here. Everything Microbundle outputs is meant for use in other tools really, tools which can and should control this setting themselves.
I'm not sure what you're assuming my 'desired reaction' is here.
Your desired reaction would be a positive one, I'd imagine.
The problem is that this comes off as incredibly spammy, especially as it's mistargeted. Copy/pasting issues on a bunch of repos just isn't a good way to go about things. I fully understand you mean well but this isn't the way to do it.
from microbundle.
Copy/pasting issues on a bunch of repos just isn't a good way to go about things. I fully understand you mean well but this isn't the way to do it.
Genuine question: Ignoring the 'mistargeted' aspect (assuming that's true and I've just misunderstood); if someone has a desire to have a useful ecosystem feature considered across a number of projects in a related category (eg. web frameworks/'UI libraries'/etc; what would you consider to be 'the way to do it'? As this seemed like the most useful and direct method I could think of for doing so.
from microbundle.
I still think this should be done on the bundler/app/user side of things, rather than in libraries, but if you want to contribute a fix, go for it.
if someone has a desire to have a useful ecosystem feature considered across a number of projects in a related category (eg. web frameworks/'UI libraries'/etc; what would you consider to be 'the way to do it'?
Frankly, you shouldn't.
If you want to see a feature land in a project you actually use, then sure, go ahead and open an issue, perhaps with a few "prior art" links. But copy/pasting the same request across multiple projects just because you read about a new feature can come off as quite demanding on OSS maintainers. Imagine if everyone was doing this.
But if did insist on doing it, you should be shortly opening a PR yourself alongside that issue request (an example of this was when some NPM people went around correcting popular packages' "repository"
fields as many were invalid or using perhaps ill-spec'd versions). Asking for the entire ecosystem to change, without investing your own time in landing it, is simply not healthy in OSS.
from microbundle.
I still think this should be done on the bundler/app/user side of things, rather than in libraries, but if you want to contribute a fix, go for it.
@rschristian I'll have to dig deeper into the code/etc here before I could answer this one way or another myself, but in case that doesn't turn up a good answer, maybe I can pre-empt getting stuck and ask ahead of time.
Given microbundle
is a 'Zero-configuration bundler', my assumption was that was literal and there was no way for a downstream user to configure it; but quickly skimming the README it seems there may be a few options available. Do you have a preference for how I implement this? Should it be a default on, and/or added as a new configurable option, etc?
If you want to see a feature land in a project you actually use, then sure, go ahead and open an issue, perhaps with a few "prior art" links. But copy/pasting the same request across multiple projects just because you read about a new feature can come off as quite demanding on OSS maintainers. Imagine if everyone was doing this.
@rschristian (Mini essay here, didn't intend it to be so long; definitely no pressure/expectation to read it all/reply in detail)
Somewhat off topic 'mini essay' response about my process
I understand your view here, though it's making some assumptions that aren't true in this case. It's not just that I 'read about a new feature' and wanted to spam it across a bunch of projects, but because that new feature would be specifically useful in my downstream workflows (eg. web app analysis), and that it being adopted across the top web frameworks/UI libraries would mean that majority of apps I come across would then support it by default.
As far as it coming off as demanding, that's definitely not my intention. I don't open issues to 'demand'; I raise a thing (bug, feature, etc) that I think would benefit the project, as an invitation to a conversation/collaboration around the thing being raised. Ultimately if it's not something a project is willing to implement/accept, that's fair enough, it's not my place to demand it (though as you no doubt inferred from our conversation on the other issue, my neurodiverse brain wants to understand the "why can't it" if the basis of a 'no' is simply more than "I don't want that in my project"; as I've found that often people can quickly jump to a conclusion that doesn't always hold true under further exploration)
Then, depending on what the thing being raised is, my time/energy (and whether my ADHD brain remembers to), I will then often try and dig into some of the deeper specifics as relevant to that specific project, and add further context on that issue for how I think it could be implemented/etc; though as I am often not deeply familiar with the projects, it can take more time/effort to figure out those specifics, and I like to have somewhere created to 'put those learnings' when I do (thus the issue). Also sometimes a maintainer jumps in before I get a chance to look at those deeper things and has ideas/pointers for where to look to implement it (or if it's something they won't accept regardless, and thus not worth me looking deeper into it).
Then finally, based on that analysis/context, either I or another contributor should be able to more quickly/easily make the specific changes required to implement/fix the thing.
I guess I sort of see it as a 'staged process', with each stage aiming to contribute some value, even if I don't manage to keep my brain/memory focussed on it long enough to see it through to the fully completed solution.
But if did insist on doing it, you should be shortly opening a PR yourself alongside that issue request
@rschristian That's totally fair. As I sort of inferred in my 'mini-essay' above, I often don't want to jump straight to a PR before there has been at least some level of "yes, sounds good" from a project; as it's not worth sinking my time/energy into implementing it if the project will just turn around and be like "no, we don't want that".
Asking for the entire ecosystem to change, without investing your own time in landing it, is simply not healthy in OSS.
@rschristian nods agreed.
from microbundle.
enabling it is fine, no need for config
@rschristian Ok, thanks for clarifying :)
I don't love that package maintainers will need to tell their consumers that they'll have to alter their browser's settings if they want the old behavior (as this seems to be enabled by default in Chrome)
@rschristian nods, understandable. Though it sounds like in many cases a new default coming in Chrome 120 would have a similar impact on a majority of bundled code anyway:
- https://developer.chrome.com/blog/new-in-devtools-120/#default-regex
-
This version enables the default regular expression as a custom exclusion rule in Settings. Settings > Ignore List. To help you focus on only your code, the Debugger will now skip scripts from
/node_modules/
and/bower_components/
by default. You can disable this rule in settings at any time.
-
And I guess for a lot of 'end-users' of libraries, in a majority of cases they aren't ever going to need to switch back to the old behaviour, as the internals of a lib aren't often super relevant to debugging web app code.
I'd expect it to theoretically be more of a potential concern to library maintainers themselves, but then they're probably not developing on the bundled/minimised version of their lib anyway, so this shouldn't impact them there either.
I get that, but unfortunately collaboration like this demands a time investment from someone: either the (potential) contributor doing work up front or the maintainers fielding questions. I know it seems like a quick thing but many of us have another 50+ repos we're fielding questions in (and even more that we're neglecting) on top of work, personal life, etc.
@rschristian nods that's totally fair, and I can understand and relate to that feel.
Opening issues for discussion/one-offs are a-okay, but if you're trying to standardize an entire ecosystem, personally, it comes off a lot more positive if you're making some initial investment to make that happen. A hacky, post-build injection in Preact's source maps (for this issue) would've been a fine starting point, for example.
@rschristian nods fair enough, I can definitely take that feedback on board :)
from microbundle.
Tracing the right place to make these changes
- https://github.com/developit/microbundle#-installation--setup--
-
Try it out by running
npm run build
.
-
- https://github.com/developit/microbundle/blob/master/package.json#L22-L24
-
"build": "npm run -s build:babel && npm run -s build:self", "build:babel": "babel-node src/cli.js --target=node --format cjs src/{cli,index}.js", "build:self": "node dist/cli.js --target=node --format cjs src/{cli,index}.js",
-
- https://github.com/developit/microbundle/blob/master/src/cli.js#L8-L9
import microbundle from './index';
- https://github.com/developit/microbundle/blob/master/src/index.js#L50
-
export default async function microbundle(inputOptions) { // ..snip.. let steps = []; for (let i = 0; i < options.entries.length; i++) { for (let j = 0; j < formats.length; j++) { steps.push( createConfig(options, options.entries[i], formats[j], j === 0), ); } } // ..snip.. let out = await series( steps.map(config => async () => { const { inputOptions, outputOptions } = config; if (inputOptions.cache !== false) { inputOptions.cache = cache; } let bundle = await rollup(inputOptions); cache = bundle; await bundle.write(outputOptions); return await config._sizeInfo; }), ); // ..snip..
-
- https://github.com/developit/microbundle/blob/master/src/index.js#L326
-
function createConfig(options, entry, format, writeMeta) {
- https://github.com/developit/microbundle/blob/master/src/index.js#L451-L702
- This seems to be the actual
config
that containsinputOptions
passed torollup
andoutputOptions
passed tobundle.write
- This seems to be the actual
-
The change to be made is in rollup
's output
config:
- https://rollupjs.org/configuration-options/#output-sourcemapignorelist
-
output.sourcemapIgnoreList
Type:boolean | (relativeSourcePath: string, sourcemapPath: string) => boolean
A predicate to decide whether or not to ignore-list source files in a sourcemap, used to populate thex_google_ignoreList
source map extension.
When you don't specify this option explicitly, by default it will put all files withnode_modules
in their path on the ignore list. You can specifyfalse
here to turn off the ignore-listing completely.
-
Based on the description of that rollup
config option, since microbundle
is designed for libraries, I believe it should be fine to just pass true
here, and ignore-list all of the library files.
Based on the above exploration of microbundle
's code, it looks like the outputOptions
config passed to rollup
are defined here:
So the entire change to implement this is probably just:
// ..snip..
outputOptions: {
// ..snip..
sourcemap: options.sourcemap,
+ sourcemapIgnoreList: true,
// ..snip..
},
// ..snip..
After making that, I was getting some warnings while running npm test
:
console.warn
Unknown output options: sourcemapIgnoreList. Allowed options: amd, assetFileNames, banner, chunkFileNames, compact, dir, dynamicImportFunction, entryFileNames, esModule, exports, extend, externalLiveBindings, file, footer, format, freeze, globals, hoistTransitiveImports, indent, inlineDynamicImports, interop, intro, manualChunks, minifyInternalExports, name, namespaceToStringTag, noConflict, outro, paths, plugins, preferConst, preserveModules, preserveModulesRoot, sourcemap, sourcemapExcludeSources, sourcemapFile, sourcemapPathTransform, strict, systemNullSetters
output.sourcemapIgnoreList
was added to rollup
in 3.16.0
(2023-02-17
):
- https://github.com/rollup/rollup/blob/master/CHANGELOG.md#3160
-
Support
output.sourcemapIgnoreList
option to mark file sources as ignored in thex_google_ignoreList
attribute of the resulting sourcemap (rollup/rollup#4848)
-
microbundle
is using a super outdated version of rollup
(2.35.1
) from 2020-12-14
:
Line 102 in c76c41f
So before we can implement this change, we'll need to upgrade to a modern version of rollup
.
I'll work on getting that change implemented and hopefully put up a PR for it shortly.
Edit: Maybe not so shortly, as it looks like microbundle
's version of rollup
is super outdated (using 2.35.1
, and this flag isn't supported till 3.16.0
. Opened a new issue to track this:
from microbundle.
Related Issues (20)
- Using for of loop adds ~300 bytes of polyfill code HOT 5
- CSS var default `transparent` becomes `#0000` (Version 0.15.1) HOT 4
- Environment variables HOT 3
- Facing difficulty in using my bundled package HOT 2
- inline of dependency leads to failed imports in source HOT 14
- No name was provided for external module 'preact/compat' HOT 2
- Build for React Server Components HOT 7
- Alias are specific only? HOT 2
- Wrong "import" in UMD bundle of UMD package HOT 8
- 打包后的产物 x.moduel.mjs 存在箭头函数,导致IE 无法兼容 HOT 3
- update rollup from 2.35.1 (2020-12-14) to at least 3.16.0 (2023-02-17), or ideally latest (4.6.1, 2023-11-30) HOT 12
- Cannot build when importing @sentry/browser HOT 5
- Dymanic imports not working in next.js and webpack applications HOT 2
- [typing import error][help wanted] The {{ package-name }} library may need to update its package.json or typings. HOT 8
- How can I include SVGs into my build? HOT 16
- Using React 17 or 18 i get the following error rpt2: options error TS5089: Option 'jsxFactory' cannot be specified when option 'jsx' is 'react-jsx'. HOT 1
- prevent export merge HOT 5
- Microbundle is awesome!
- Error when using file JS built by microbundle "Uncaught ReferenceError: require is not defined" HOT 17
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from microbundle.