Fails on windows 7

[ibesora]

I'm trying to generate the Mapbox documentation from source using yarn start-docs and the command fails with the following error:

SyntaxError: Bad character escape sequence (12:18)
               getPage: () => import(
                 /* webpackChunkName: "mapbox-gl-js" */
                'E:\usuaris\i.besora\workspace\mapbox-gl-js  \_batfish_tmp\_mapbox-gl-js.js'

It seems the paths are not correctly generated on windows.

[davidtheclark]

@ibesora: Thanks for the issue. I haven't been dealing with Windows for a while, so it's not surprising that I let something slip 😬

@asheemmamoowala is this similar to the Windows error you saw the other day?

For this particular error, I'm betting that the bug is in https://github.com/mapbox/batfish/blob/068a3912d5c340028e4e8b1422b7206d04716b34/src/node/write-page-module.js#L21-L25

There are some assumptions there about the path separator. Oops.

@ibesora & @asheemmamoowala: Since you have Windows all set up and ready to go, would you mind spending a minute changing those lines and seeing if that fixes the problem? (It's quite possible that if it does another problem of the same type pops up somewhere else.)

[asheemmamoowala]

@davidtheclark I was actually stuck on a previous error. That was related to mixed path separators when using a bash terminal on Windows. To fix that problem I had to add a replace('\','/') at the end of pageFilePathToUrlPath in : https://github.com/mapbox/batfish/blob/246635c74000b5903a2bdc5547e4646dc3c7255f/src/node/get-pages-data.js

Fixing that got me to the issue reported by @ibesora above.

The error shown above stems from pageModuleFilePath in write-context-module.js, using un-escaped paths. Converting single \ to \\ or / fixes the issue on Windows. There are no path methods to do this consistently, so I've put in a replace('\','/') there as well.

Any use of path.relative and possibly path.join can cause trouble on Windows systems.

[davidtheclark]

Any use of path.relative and possibly path.join can cause trouble on Windows systems.

@asheemmamoowala Really? I thought the point of these path functions was to get filesystem-tailored filepaths that you can rely on?

There are a variety of regular expressions in the codebase that are used to identify files but are not safe for Windows. Above, we have /\//; in other places it might be /foo\/bar/. From what I found with a quick search, I think (\\|\/) should be inserted into these file-separator spots for Window-safe regular expressions. I'll give that a shot soon.

[asheemmamoowala]

Really? I thought the point of these path functions was to get filesystem-tailored filepaths that you can rely on?

I may have exaggerated a little bit 😁 One problem is with writing the relative paths to a config file, and the other is with the regexp not working on posix systems with whitespace in the file path.