import xxx = require('xxx') seems to be silently removed

[whitetrefoil]

Versions

• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]

rollup.config.js

const commonjs          = require('rollup-plugin-commonjs')
const nodeRes           = require('rollup-plugin-node-resolve')
const typescript        = require('rollup-plugin-typescript')

module.exports = {
  entry    : './src/api/test.ts',
  format   : 'cjs',
  dest     : './.building/api/test.js',
  treeshake: false,
  plugins  : [
    typescript({
      typescript: require('typescript'),
    }),
    commonjs(),
    nodeRes({
      extensions: ['.ts', '.js', '.json'],
    }),
  ],
}

test.ts (input)

// Start

import lodash = require('lodash')
console.log(lodash)

// End

test.js (output)

// Above are typescript helpers, like `__assign`, `__awaiter`, etc....

// Start
console.log(lodash);
// End

[knpwrs]

I just ran into this myself. Are there any workarounds? I'm trying to do the following:

import uniq = require('lodash/uniq');

Attempting to tree-shake lodash-es is not working for me.

[lukastaegert]

This does not look like valid TypeScript syntax to me as it is mixing the ES module format with the CommonJS module format. Does

import uniq  from 'lodash/uniq';

work for you? You may also need rollup-plugin-node-resolve before rollup-plugin-typescript to resolve the import, though.

[knpwrs]

It is valid TypeScript. This is how TypeScript imports CommonJS. See https://github.com/DefinitelyTyped/DefinitelyTyped/blob/5099333846e466f1583b5e254dea18c9b7384325/types/lodash/lodash-tests.ts#L1-L2 and a number of other CommonJS typings in the definitely typed repo.

[lukastaegert]

I see. It seems this is stripped out by TypeScript if the module type is ES2015 or ESNext, which is not surprising as CommonJS is not compatible with ES modules. One approach could be to allow CommonJS as a valid module format while leaving it to the user to add rollup-plugin-commonjs to transpile back to ES modules afterwards. Which will change execution semantics slightly and may not work in some situations. But I know no better solution.

[lukastaegert]

I have added this approach to #124 and documented it in the README