electron-userland / electron-compilers Goto Github PK

I was going to work on creating a pull request for Haml support (also setting up a compiler for HTML), but wasn't sure if this is something you wanted. Just opening an issue to discuss.

The typescript compiler seems to ignore or stomp on this configuration option.

Making this available should reduce ecosystem compatibility problems; I suspect it will address the issues in electron-userland/electron-compile#294.

The commit ffbd700 introduced a regression. The following repro steps fail with 5.3.0 and 5.3.1 and succeeds with 5.2.5.

Repro steps

1. Install Electron Forge
2. Run electron-forge init something
3. Run cd something
4. Run electron-forge package

Expected

A package is created for the host platform & arch.

Actual

✔ Checking your system
✔ Preparing to Package Application for arch: x64
⠋ Compiling ApplicationCouldn't set up compilers: Cannot find module 'typescript/package.json'
✖ Compiling Application

An unhandled error has occurred inside Forge:
Cannot find module 'typescript/package.json'
Error: Cannot find module 'typescript/package.json'
    at Function.Module._resolveFilename (module.js:469:15)
    at Function.Module._load (module.js:417:25)
    at Module.require (module.js:497:17)
    at require (internal/module.js:20:19)
    at TypeScriptCompiler.getCompilerVersion (/tmp/something/node_modules/electron-compilers/lib/js/typescript.js:70:12)
    at Object.keys.reduce (/tmp/something/node_modules/electron-compile/lib/compiler-host.js:496:35)
    at Array.reduce (native)
    at CompilerHost.saveConfigurationSync (/tmp/something/node_modules/electron-compile/lib/compiler-host.js:488:72)
    at createCompilerHostFromConfiguration (/tmp/something/node_modules/electron-compile/lib/config-parser.js:323:7)
    at /tmp/something/node_modules/electron-compile/lib/config-parser.js:80:12
    at next (native)
    at step (/tmp/something/node_modules/electron-compile/lib/config-parser.js:179:191)
    at /tmp/something/node_modules/electron-compile/lib/config-parser.js:179:361

When npm install is run, this is one of the warnings ([email protected] is installed):

UNMET PEER DEPENDENCY typescript@>=1.6

It looks like Sass used to be supported, but isn't any longer. Is there a reason as to why? Would you be open to pull requests to reimplement it?

Hey all,

I am working on a project which is in a monorepo and the react components are in a separate package which are all connected by lerna. But if I use it with react-hot-loader it totally borks electron-compile & it complains:

Uncaught Error: Couldn't find preset "react-hot-loader" relative to directory "/Volumes/*/universal-react/packages/components/src"

Any idea how to fix this? It seems to be looking at the node_modules folder in the components package rather than the actual project's node_module folder

Thanks a bunch....

This issue applies both to electron-compile and electron-compilers, sorry

Reading through a bunch of code right now to find out if a different $TEMP/compileCache_${hash} will get generated if NODE_ENV changes, and.. it doesn't like it does?

Here's the default cache directory code:

export function calculateDefaultCompileCacheDirectory() {
  let tmpDir = process.env.TEMP || process.env.TMPDIR || '/tmp';
  let hash = require('crypto').createHash('md5').update(process.execPath).digest('hex');

  let cacheDir = path.join(tmpDir, `compileCache_${hash}`);
  mkdirp.sync(cacheDir);

  d(`Using default cache directory: ${cacheDir}`);
  return cacheDir;
}

The problem is:

• One might want to enable code coverage (or other babel plugins) only in testing
• But since all files are cached by their content
• And the files wouldn't change, only the compiler settings would
• Then electron-compile would just happily serve the old cached versions (which may have coverage instrumentation when they shouldn't, and the other way around).

You can probably reproduce the problem easily if you use electron-compile with a .babelrc like:

{
  "env": {
    "production": {
      "presets": ["es2016-node5", "react"],
      "sourceMaps": false
    },
    "development": {
      "presets": ["es2016-node5", "react"],
      "sourceMaps": "inline"
    }
  }
}

run it once with NODE_ENV=production, then again with NODE_ENV=development, I'm 80% confident you'd end up not seeing sourceMaps still.

Here's my proposal for electron-compile:

• Change calculateDefaultCompileCacheDirectory to feed off of
  • process.execPath
  • process.env.NODE_ENV || "development"
  • the digest for the info/config/opts object (using digest-for-object)
  • see fasterthanlime/electron-compile@a072baf

Tangentially, here's what I've got planned for electron-compilers:

• Add way for compilers to get an input sourceMap
  • compilerContext seems okay
• Make babel compiler consume that input sourceMap when it's there
  • see fasterthanlime@a98839a
• Drop sorcery dependency
  • see fasterthanlime@a98839a
• Make both coverage options (typescript & babel) only apply when NODE_ENV=test
  • Alternatively: only do env matching when coverage is a string, and coverage: true would always instrument, so that the old behavior is retained?
  • Alternatively: don't change anything about the coverage option, force folks to use env blocks
  • see fasterthanlime@a98839a
• Make both coverage option use babel-plugin-istanbul (a relatively thin wrapper over new-istanbul's instrumenting lib).
  • For babel, this means pushing adding a plug-in to the plugins list
  • For typescript, this.. requires babel :/
  • see fasterthanlime@a98839a
• Drop dependency to istanbul 0.4.5 (legacy istanbul) - it's somehow still in electron-compile's package.json
  • see fasterthanlime/electron-compile@e7c2dde
• Document how to set up typescript+babel (babel block in the typescript config)
  • see fasterthanlime/electron-compile@1f7a795
• Document how to set up coverage instrumentation
  • see fasterthanlime/electron-compile@1f7a795
• Document what coverage instrumentation does (collects coverage info using the new istanbul, aka istanbuljs/istanbuljs, into the global __coverage__ variable)
  • see fasterthanlime/electron-compile@1f7a795
• Give an example of collecting/reporting from a __coverage__ variable, with proper sourceMap support (it's like 8 lines).
  • see fasterthanlime/electron-compile@1f7a795

Let me know if any of that sounds bad @paulcbetts & others so I can adjust plans accordingly!

Hi, I'm trying to use electron-compile to compile a sass file.
I have to import bootstrap-sass, so I pass includePaths option to electron-compile

require('electron-compile').initWithOptions({
  cacheDir: join(__dirname, '/cache'),
  compilerOpts: {
    // Compiler options are a map of extension <=> options for compiler
    js: { stage: 0},
    scss: { includePaths: [
       join(__dirname, 'node_modules/bootstrap-sass/assets/stylesheets'),
        ]};
  }
});

But it appear that the option is just ignored...
Digging in source files, I think I found that the problem is in electron-compilers/src/css/scss.js.

In method compile, you are overriding the includePaths option:

compile(sourceCode, filePath) {
    let paths = Object.keys(this.seenFilePaths);
    paths.unshift('.');

    let opts = _.extend({}, this.compilerInformation, {
      data: sourceCode,
      indentedSyntax: filePath.match(/\.sass$/i),
      sourceMapRoot: filePath,
      includePaths: paths,
      filename: path.basename(filePath)
    });

    let result = scss.renderSync(opts);
    return result.css.toString('utf8');
  }

I solved the problem by do a concat with the given option, saved in constructor:

compile(sourceCode, filePath) {
    let paths = Object.keys(this.seenFilePaths);
    paths.unshift('.');

   /////////////////////   /////////////////////   /////////////////////  
    paths = paths.concat(this.compilerInformation.includePaths);
   /////////////////////   /////////////////////   /////////////////////  
    let opts = _.extend({}, this.compilerInformation, {
      data: sourceCode,
      indentedSyntax: filePath.match(/\.sass$/i),
      sourceMapRoot: filePath,
      includePaths: paths,
      filename: path.basename(filePath)
    });

    let result = scss.renderSync(opts);
    return result.css.toString('utf8');
  }

If you think my solution it's ok, I can prepare a PR

it appears the old file wasnt cleared before publishing. Additionally, it's still referenced in src/main.js, so rebuilding kills it.

I use Stylus primarily. Stylus is made in JavaScript, so it should be okay.

The dependency of debug-electron should be updated to a version higher than 0.0.2 e.g. 0.0.4.

It'd be nice to be able to set extends in .compilerrc to point to a tsconfig.json file. Then the development configuration could be the same as specified in tsconfig.json.

{
  "env": {
    "development": {
       "text/typescript": {
         "extends": ["../path/to/tsconfig"]
       }
    }
  }
}

I used electron-compile (with electron-compilers) a while ago but since electron-builder didn't support it, I had a toolchain that first transpiled JSX using babel and then ran electron from the directory where the transpiled files where at. Now that electron-builder finally supports electron-compile, I wanted to switch back. Unfortunately, using electron-prebuilt-compile, I was unable to start the project.

The error is caused because I am importing webpack 2.x in my electron main thread import webpack from 'webpack'. If I remove the import electron-compile works fine.

I believe that the issue is somewhere in this package, maybe because babel is iterating over node_modules or something?

This is the error I receive:

App threw an error during load
C:\workspace\js\sites-app\node_modules\webpack\lib\WebpackOptionsApply.js:209
                        comment = legacy && modern ? "\n/*\n//@ sourceMappingURL=[url]\n//# sourceMappingURL=node_modules\webpack\lib\[url]\n*\" :
                                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
SyntaxError: Invalid or unexpected token
    at Object.exports.runInThisContext (vm.js:78:16)
    at Module._compile (module.js:543:28)
    at Object.require.extensions.(anonymous function) [as .js] (C:\workspace\js\sites-app\node_modules\electron-compile\lib\require-hook.js:75:14)
    at Module.load (module.js:488:32)
    at tryModuleLoad (module.js:447:12)
    at Function.Module._load (module.js:439:3)
    at Module.require (module.js:498:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (C:\workspace\js\sites-app\node_modules\webpack\lib\webpack.js:10:29)
    at Object.<anonymous> (C:\workspace\js\sites-app\node_modules\webpack\lib\webpack.js:121:3)
    at Module._compile (module.js:571:32)
    at Object.require.extensions.(anonymous function) [as .js] (C:\workspace\js\sites-app\node_modules\electron-compile\lib\require-hook.js:75:14)
    at Module.load (module.js:488:32)
    at tryModuleLoad (module.js:447:12)
    at Function.Module._load (module.js:439:3)
    at Module.require (module.js:498:17)

When I inspect the code, I see that there is a small difference. Above, the line escapes the last quote:

comment = legacy && modern ? "\n/*\n//@ sourceMappingURL=[url]\n//# sourceMappingURL=node_modules\webpack\lib\[url]\n*\" :

while in the code, the last quote is not escaped:

comment = legacy && modern ? "\n/*\n//@ sourceMappingURL=[url]\n//# sourceMappingURL=[url]\n*/"

Additionally, it seems like the string node_modules\webpack\lib was injected.

When setting DEBUG=* these are the logs:

$ npm run start:electron | grep WebpackOptionsApply
Fri, 14 Apr 2017 16:20:12 GMT electron-compile:compiler-host Compiling C:\workspace\js\sites-app\app\node_modules\webpack\lib\WebpackOptionsApply.js
Fri, 14 Apr 2017 16:20:12 GMT electron-compile:sanitize-paths Cache miss for cachedRealpath: 'C:\workspace\js\sites-app\app\node_modules\webpack\lib\WebpackOptionsApply.js' => 'C:\workspace\js\sites-app\app\node_modules\webpack\lib\WebpackOptionsApply.js'
Fri, 14 Apr 2017 16:20:12 GMT electron-compile:file-change-cache Cache entry for /node_modules/webpack/lib/WebpackOptionsApply.js: {"ctime":1491859282178,"size":11342,"info":{"hash":"2285a98358d4b0997095fe757b2cfa80ef920276","isMinified":false,"isInNodeModules":tr
ue,"hasSourceMap":false,"isFileBinary":false}}
C:\workspace\js\sites-app\app\node_modules\webpack\lib\WebpackOptionsApply.js:209 # this is the error

This is an upstream to electron-userland/electron-compile#210

Hi, i'm getting Not found : @paulcbetts/node-sass when running npm install electron-compilers --save-dev. Did @paulcbetts/node-sass get unpublished or something? Or am i doing something wrong?

Thanks for your help.

When building a file cache for installation, the inline-html.js compiler appears to set the x-require src value to an absolute path based on the build machine's directory structure at the time of build.

Not sure if this is a bug or if I'm doing something wrong here.

The ws module exports WebSocket like so:

// `ws` module
module.exports = WebSocket;

I'm importing WebSocket from the ws module like so:

// server.ts
import 'WebSocket' from 'ws';

const Server  = new WebSocket.Server(options);

Seems fine, right?
Well, it is being compiled to the following:

var ws_1 = require("ws");

var Server = new ws_1.default.Server(options);

The problem is that ws_1.default is undefined. It should be compiled to ws_1.Server, should it not?

I am currently experiencing an issue that I think I have been able to track back to electron-compilers. I think the issue is that the electron-compilers/src/html/jade.js compiler doesn't implement the determineDependentFiles() function. It is also possible that I'm mistaken. If that's the case, then I apologize.

I found this by trying to use electron-forge which uses electron-compile for compiling jade. I created a jade template that called out to a partial. Updating the partial would not cause the parent file to be recompiled as I expected. However, updating the parent file would cause the partial to be recompiled.

I am pretty new to node.js and electron. I have more experience with Ruby. But I'm willing to take a stab at implementing this, with a little guidance.

For reference, I have created a repo to showcase the problem here: https://github.com/alexshenoy/jade-compiler-troubleshooting

Steps To Reproduce:

1. Run npm start
2. Modify partial.jade
3. Run npm start again
4. See cached index.html instead of new version.

Relevant code from the repo:

createWindow() from index.js:

const createWindow = () => {
  mainWindow = new BrowserWindow({
    width: 800,
    height: 600,
  });
  mainWindow.loadURL(`file://${__dirname}/index.jade`);
  mainWindow.on('closed', () => {
    mainWindow = null;
  });
};

index.jade:

doctype html
html
  head
    title Electron Playground
  body
    include ./partial
    Hi Mom!! Test of some kind

partial.jade

h4 This is a title
p.
  Changes in this file will not be reflected in the above partial.

The coffee-script dependency (at least for me) no longer installs coffeescript and prints a warning to the console. Instead, it breaks the install:

$ npm install --save-dev electron-compilers
npm ERR! code E404
npm ERR! 404 Not Found: coffee-script@^1.10.0

Merging in this pull request should fix the issue.