lukeed / rewrite-imports Goto Github PK
View Code? Open in Web Editor NEWRewrite `import` statements as `require()`s; via RegExp
License: MIT License
Rewrite `import` statements as `require()`s; via RegExp
License: MIT License
Based on your examples provided, I don't think you are properly supporting esm imports.
const rImports = require('rewrite-imports');
rImports(`import * as a from './a';`);
//=> const a = require('./a');
rImports(`import a from './a';`);
//=> const a = require('./a').default;
rImports(`import { default as a } from './a';`);
//=> const { default: a } = require('./a');
rImports(`import a, { default as b } from './a';`);
//=> const a = require('./a').default;
//=> const { default: b } = require('./a');
This is because import a from './a'
!== import * as a from './a'
@sapegin What do you think about transforming imports to their more succinct require
counterparts?
import { foo, bar } from 'foobar';
//=> const { foo, bar } = require('foobar');
In order to do this safely, we just have to check that
a) there is no alias (as
) attempt
b) there is no mixed import statement (#10)
If either of those are true, we have to bail and fallback to the current transformation.
Similarly, it might be nice to do the aliasing/partials with destructuring. I think that transforming those is the role of a Babel-type player.
Given your use-case, I'm interested in your thoughts. This probably warrants a 2.0 given the change in output.
import foobar, { foo, bar } from 'foobar';
// Current:
const foobar = require('foobar');
const foo = foobar.foo;
const bar = foobar.bar;
// After:
const foobar = require('foobar');
const { foo, bar } = foobar;
import { foo as FOO, bar } from 'foobar';
// Current:
const foobar = require('foobar');
const FOO = foobar.foo;
const bar = foobar.bar;
// After:
const foobar = require('foobar');
const { foo:FOO, bar } = foobar;
//^ Still Node 6.x compatible
Greetings. I maintain esbuild-svelte
and recently ran across what I believe is an incorrect transform. The version w/ the incorrect code is v0.5.5
(see line 23) and I did a "emergency" fix with v0.5.6
that solved the issue (by disabling the new code I added).
Minimum reproduction, removing the declaration of filename
, contents
or the text
property containing doesn't
causes the code to transform just fine. I've replaced any text that didn't seem to matter with N/A
import { relative } from "path";
function sveltePlugin() {
return {
name: "N/A",
setup(build) {
build.onLoad({ filter: /N\/A/ }, () => {
return {
errors: [
{
text: "doesn't"
}
]
};
});
build.onLoad({ filter: /N\/A/ }, (args) => {
let filename = relative(process.cwd(), args.path);
let contents = `N/A
import "${"something"}";`;
return null;
});
}
};
}
export {
sveltePlugin as default
};
The unexpected result is:
require(";`);
return null;
});
}
};
}
export {
sveltePlugin as default
};
I know this can get real complex for parsing! I see the false positives warning and #8 so please close this if it's out of scope to fix, just figured I'd pass on a semi-real world example.
Thanks for your work!
For this input:
rewriteImports(`import bar, { foo } from 'bar'`);
The result would be:
function ri$interop(m){return m.default||m}
const bar = ri$interop(require('bar'));
const foo = bar.foo;'
bar
will be already m.default
, so foo
will be m.default.foo
which is incorrect.
And I'm not really sure we should try to solve it in the library itself, probably just removing interop would be a better solution. I'm still using 1.2 in Styleguidist because of that — I need a custom interop function.
Maybe we could make require
function name configurable, so users could have their custom implementation before calling actual require
.
I found a few false positive cases, where the library replaces imports where it shouldn't. But I'm not sure trying to fix that will be in the scope of the library. Probably I'll just allow imports
only at the beginning of the file — they supposed to be hoisted anyway.
const line = "import foo from 'foo'"
const line = 'import foo from "foo"'
const line = `import foo from 'foo'`
<p>import foo from 'foo'</p>
Would it be possible to not use bundt to build rewrite-imports as rewrite-imports is a run time dependency of bundt and a clean bootstrapping from source is complicated now?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.