Skip to content
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

Tree shaking in dynamic modules #3447

Closed
jakearchibald opened this issue Mar 18, 2020 · 10 comments · Fixed by #4952
Closed

Tree shaking in dynamic modules #3447

jakearchibald opened this issue Mar 18, 2020 · 10 comments · Fixed by #4952

Comments

@jakearchibald
Copy link
Contributor

Feature Use Case

Repl example.

export2 is unused but appears in the bundle.

Feature Proposal

Object shape tracking was mentioned in #3417 (comment).

I'm aware this issue has been discussed in many other issues, but it felt like it didn't have its own issue. Feel free to close if it doesn't need one.

@frank-dspeed
Copy link
Contributor

I think this is overall impossible

import(variable)

we will never know what gets used and whats not get used as it could be even imported in other context as well.

but we can keep it open maybe we have in future some sort of AI that can guess that after a full pupeteer test or something like that

@rollup-bot
Copy link
Collaborator

I would not say that but at current priorities, I would give this a time frame of up to a year. Object property tree-shaking will be a pre-requisite to pull this off comprehensively. If we want a short-cut, one might try to code in some special cases first.

@lukastaegert
Copy link
Member

Oops, wrong account, now that was funny

@mischnic
Copy link

future some sort of AI

Indeed...

@guybedford
Copy link
Contributor

guybedford commented Jul 10, 2020 via email

@jakearchibald
Copy link
Contributor Author

@frank-dspeed

I think this is overall impossible

import(variable)

Right, but that isn't what this issue is about. This is about cases where the bundler knows which module is being imported.

@frank-dspeed
Copy link
Contributor

frank-dspeed commented Jul 14, 2020

@jakearchibald such code splitting is possible via wrappers

original-module.js

exports  { me, him, watson, otherDog, cat}

wrapper-i-call-this-lib.js

exports { watson, otherDog } from './original-module.js'

myapp.js

import { watson } from './wrapper-i-call-this-lib.js'
console.log(watson,'a cute dog')

other-part-of-app.js

import('./wrapper-i-call-this-lib.js').then(({ otherDog })=>console.log('Not as cute as watson))

Resulting

cunk of wrapper-i-call-this-lib.js that is shared will still contain only watson and otherDog

exports { watson, otherDog } from './original-module.js'

Update (15.08.20)

Repl example of the problem.

Repl example of the Solution

@frank-dspeed
Copy link
Contributor

@jakearchibald the wrapper or lib.js is the file where you can put your information about the import exports that are used project wide that also allows easy code injection for tests and all that.

@frank-dspeed
Copy link
Contributor

After working now some month on the vscode rollup integration i regonized that the algo that typescript uses is able to do this via unused vars so we rollup could reuse the typescript ast via a adapter at present and maybe also on the long run replace acornjs with typescript

we could also replicate the typescript algo that allows to do so but i am not a big fan of that idea.as we do not have the man power for it while it would be cool to do a acorn js version of un used variables inside a project

The most fast way would be to give the acorn ast to typescript then get from typescript the un used variables and strip them.

@rollup-bot
Copy link
Collaborator

This issue has been resolved via #4952 as part of rollup@3.21.0. You can test it via npm install rollup.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants