Thoughts on building esm at python packaging time
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 134
- Forks
- 9
- PR merge metrics
- No merged PRs in 30d
Description
What are your thoughts on a pattern like this?
In the future, when I care about bundle sizes of my widget, I would prefer not to ship sucrase in the bundled JS. My _esm cproperties are very small, essentially shims between my component library and ipyreact. What would it look like if there was no sucrase shipped with js bundle. (I'm not worried about the time it takes to execute sucrase, this should be minimal.
What if the _esm blocks were hashed and compiled in a step. Then there was a shipped dictionary from _esm_hash to compiled js. The frontend code references this dictionary in production mode, and the 1mb sucrase dependency doesn't ship.
This is a pretty advanced optimization that I don't think I'll get to for a while, if ever. but curious on your thoughts
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
The issue proposes compiling and hashing _esm blocks during Python packaging so production can use a dictionary instead of shipping sucrase. No files or tests are named; start by tracing _esm handling, the sucrase bundle, and the production frontend entry point. Done means the production bundle omits sucrase while the packaged _esm behavior remains available.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python, react, typescript
- Domain
- build-system, frontend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100