Currently, arguments in require are processed by tstl's module resolution. However, sometimes I want an escape hatch from tstl's module resolution and just use raw lua require behavior (due to the environment). There currently is no good way to do this. There is a workaround like below:

const modName = "someModule.foo"
const bar = require(modName)

This highlights the inconsistency in how string arguments in require functions are automagically processed, but variables are not.

Here are some possible solutions to this:

• Let only import statements use module resolution, and leave require statements alone. This would be a backwards incompatible change. However, require() is a a function only defined in lualib, so it could make sense for it to follow the same behavior as plain lua. This would also remove the inconsistency between using/not using a string literal as an argument to require.

• Looking through the code base, specifying require("@NoResolution:someModule)" is already a way currently to get around resolution. This could be officially supported/documented, and still allows requiring TS-style imports.

• Invert the previous method and have only require("@ts:someTsModule") be processed by module resolution. This would get some of the best parts of the above 2 ideas, but would make it harder for tooling to detect such requires.

• Introduce a language extension function $require that translates to plain lua require, and leave require currently as is. Or, inverted, $require should use module resolution and plain require does not.