Macro import paths with Windows separators are ignored

• babel-plugin-macros version: 2.6.1
• node version: 12.6.0
• npm (or yarn) version: yarn 1.16.0

Relevant code or config

import { _ } from '.\\macro'
import { it } from 'E:\\dev\\param.macro\\macro'

I came across this when testing param.macro and have noticed that tests will fail on Windows — the import path I generate for testing (an absolute Windows style path) is ignored by babel-plugin-macros but is also further incompatible with it.

What you did:

Compile

What happened:

The macro is not activated.

Reproduction repository:

1. git clone https://github.com/citycide/bpm-repro.git
2. yarn
3. yarn build
4. dist.js is created but was not transformed

Problem description:

1. the macro regex only accounts for a unix path separator (/)
2. even once 1) is fixed, the resolve module throws MODULE_NOT_FOUND

Suggested solution:

First the regex would need to be updated to something like this:

https://github.com/kentcdodds/babel-plugin-macros/blob/2d57c60adadd8904db9624614faffc34a251c40d/src/index.js#L5

- const macrosRegex = /[./]macro(\.js)?$/
+ const macrosRegex = /[./\\]macro(\.js)?$/

However this isn’t enough as once applyMacros is actually called, the resolve module will throw:

Error: Cannot find module '.\macro' from 'E:\dev\param.macro'

---

There are existing issues that mention Windows but they all relate to tests.

[sokra]

If the host environment is webpack, absolute windows paths are allowed. Relative paths with windows separator are not.

[sompylasar]

I believe Node.js source can be considered a reference implementation.

It says that the thing you put in the import statement is called “module_request” (which not necessarily maps to a file system path 1:1). https://github.com/nodejs/node/blob/2983eaca84e9e79c19dba09fb036fe55131b8a5d/deps/v8/src/ast/modules.h#L37

It goes to GetModuleNamespace which is an abstract ECMAScript operation https://github.com/nodejs/node/blob/8aca934009225b30bff7d7927d2eb9f667dbff9f/deps/v8/src/runtime/runtime-module.cc#L38

https://tc39.es/ecma262/#sec-getmodulenamespace

That mentions the HostResolveImportedModule abstract operation which depends on the implementation of the host environment.

So the answer is actually “the spec says it depends on the host environment”.