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?

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!

@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

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'

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>

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.