New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable install and build using node-chakracore #1777

Open
wants to merge 18 commits into
base: master
from

Conversation

Projects
None yet
9 participants
@kunalspathak

kunalspathak commented Oct 29, 2016

This PR enables windows user to install and locally build this module using node-chakracore. See nodejs/node-chakracore#136.

Individual commits have description of changes. If this is enabled, node-chakracore user can do the following in order to install node-sass module.

  • Open 'Node.js chakracore command prompt`
  • npm install

npm install would build the module locally using node-chakracore instead of downloading pre-built binary that is compiled with nodev8. See #1776.

Test result: All unit test pass.

  5908 passing (22s)
  322 pending
@xzyfer

This comment has been minimized.

Show comment
Hide comment
@xzyfer

xzyfer Nov 1, 2016

Contributor

For clarification, the crux of the issue is that node-chakracore isn't compatible with node-gyp?

Contributor

xzyfer commented Nov 1, 2016

For clarification, the crux of the issue is that node-chakracore isn't compatible with node-gyp?

Show outdated Hide outdated scripts/build.js Outdated
Show outdated Hide outdated scripts/build.js Outdated
@xzyfer

This comment has been minimized.

Show comment
Hide comment
@xzyfer

xzyfer Nov 1, 2016

Contributor

Generally speaking I'm 💯 for support chakracore. However we will either fully support it, or not support it all. IMHO half way solution is poor a experience for user, and a potential burden on us the maintainers.

To get this over the line we'll need to do the following at a minimum

  • support chakracore in the binary resolution process i.e.getBinaryName
  • update the release target in .appveyor.yml to build chakracore binaries in CI
  • update the default target in .appveyor.yml to test against chakracore in CI

Of cause I'm more than happy to help with any of the above.

Contributor

xzyfer commented Nov 1, 2016

Generally speaking I'm 💯 for support chakracore. However we will either fully support it, or not support it all. IMHO half way solution is poor a experience for user, and a potential burden on us the maintainers.

To get this over the line we'll need to do the following at a minimum

  • support chakracore in the binary resolution process i.e.getBinaryName
  • update the release target in .appveyor.yml to build chakracore binaries in CI
  • update the default target in .appveyor.yml to test against chakracore in CI

Of cause I'm more than happy to help with any of the above.

Show outdated Hide outdated scripts/build.js Outdated
@kunalspathak

This comment has been minimized.

Show comment
Hide comment
@kunalspathak

kunalspathak Nov 1, 2016

@xzyfer , I have updated the PR to address the review comments. I have also updated to address getBinaryName() for different engines. By default (for nodev8) it will retain the existing format so released binaries will continue to work and downloadable.

It will be appreciated if you can take care of appveyor.yml changes.

kunalspathak commented Nov 1, 2016

@xzyfer , I have updated the PR to address the review comments. I have also updated to address getBinaryName() for different engines. By default (for nodev8) it will retain the existing format so released binaries will continue to work and downloadable.

It will be appreciated if you can take care of appveyor.yml changes.

Show outdated Hide outdated scripts/build.js Outdated
Show outdated Hide outdated scripts/install.js Outdated
@xzyfer

This comment has been minimized.

Show comment
Hide comment
@xzyfer

xzyfer Nov 2, 2016

Contributor

@kamilogorek I'm happy to take a look. Is there any documentation to can recommend for getting node-chakracore update and running?

Contributor

xzyfer commented Nov 2, 2016

@kamilogorek I'm happy to take a look. Is there any documentation to can recommend for getting node-chakracore update and running?

@kamilogorek

This comment has been minimized.

Show comment
Hide comment
@kamilogorek

kamilogorek Nov 2, 2016

Contributor

@xzyfer are you sure that you wanted to mention me? :)

Contributor

kamilogorek commented Nov 2, 2016

@xzyfer are you sure that you wanted to mention me? :)

@xzyfer

This comment has been minimized.

Show comment
Hide comment
@xzyfer

xzyfer Nov 2, 2016

Contributor

@kamilogorek I did not, apologies.

@kunalspathak

I'm happy to take a look. Is there any documentation to can recommend for getting node-chakracore update and running?

Contributor

xzyfer commented Nov 2, 2016

@kamilogorek I did not, apologies.

@kunalspathak

I'm happy to take a look. Is there any documentation to can recommend for getting node-chakracore update and running?

@kamilogorek

This comment has been minimized.

Show comment
Hide comment
@kamilogorek

kamilogorek Nov 2, 2016

Contributor

@xzyfer no worries! glad I could help :)

Contributor

kamilogorek commented Nov 2, 2016

@xzyfer no worries! glad I could help :)

@xzyfer xzyfer referenced this pull request Nov 2, 2016

Open

Node.js on ChakraCore #1148

@xzyfer

This comment has been minimized.

Show comment
Hide comment
@xzyfer

xzyfer Nov 2, 2016

Contributor

I've opened a feature request with AppVeyor for Chakracore support. appveyor/ci#1148

Contributor

xzyfer commented Nov 2, 2016

I've opened a feature request with AppVeyor for Chakracore support. appveyor/ci#1148

@xzyfer

This comment has been minimized.

Show comment
Hide comment
@xzyfer

xzyfer Nov 2, 2016

Contributor

@kunalspathak can you please follow the steps in https://github.com/blog/2247-improving-collaboration-with-forks so I can collaborate on this PR.

Contributor

xzyfer commented Nov 2, 2016

@kunalspathak can you please follow the steps in https://github.com/blog/2247-improving-collaboration-with-forks so I can collaborate on this PR.

@kunalspathak

This comment has been minimized.

Show comment
Hide comment
@kunalspathak

kunalspathak Nov 2, 2016

@xzyfer

can you please follow the steps

I have enabled "Allow edits from maintainers" for this PR.

Is there any documentation to can recommend for getting node-chakracore update and running?

In appveyor/ci#1148, you have already added link to node-chakracore's release page. One last thing is we need to build binding.node from Node.js (chakracore) command prompt that comes when node.js chakracore is installed.
Let me know if you need any other information to get this done.

kunalspathak commented Nov 2, 2016

@xzyfer

can you please follow the steps

I have enabled "Allow edits from maintainers" for this PR.

Is there any documentation to can recommend for getting node-chakracore update and running?

In appveyor/ci#1148, you have already added link to node-chakracore's release page. One last thing is we need to build binding.node from Node.js (chakracore) command prompt that comes when node.js chakracore is installed.
Let me know if you need any other information to get this done.

Show outdated Hide outdated lib/extensions.js Outdated
Show outdated Hide outdated scripts/build.js Outdated
@xzyfer

This comment has been minimized.

Show comment
Hide comment
@xzyfer

xzyfer Nov 2, 2016

Contributor

@kunalspathak specifically I'm trying to install node-chakracore from the release binaries in our CI.

See my attempts in https://github.com/sass/node-sass/blob/trash/chakra/appveyor.yml#L122-L126
and the resulting build failure https://ci.appveyor.com/project/sass/node-sass/build/2103/job/23igf1j45b47bp0c

I'm not entire sure how to deal with the msi file in CI to get a functioning node.exe.

Contributor

xzyfer commented Nov 2, 2016

@kunalspathak specifically I'm trying to install node-chakracore from the release binaries in our CI.

See my attempts in https://github.com/sass/node-sass/blob/trash/chakra/appveyor.yml#L122-L126
and the resulting build failure https://ci.appveyor.com/project/sass/node-sass/build/2103/job/23igf1j45b47bp0c

I'm not entire sure how to deal with the msi file in CI to get a functioning node.exe.

@nschonni

This comment has been minimized.

Show comment
Hide comment
@nschonni

nschonni Nov 2, 2016

Contributor

@xzyfer you might try the same as what AppVeyor does for the supported versions https://github.com/appveyor/ci/blob/master/scripts/nodejs-utils.psm1#L116

Contributor

nschonni commented Nov 2, 2016

@xzyfer you might try the same as what AppVeyor does for the supported versions https://github.com/appveyor/ci/blob/master/scripts/nodejs-utils.psm1#L116

@kunalspathak

This comment has been minimized.

Show comment
Hide comment
@kunalspathak

kunalspathak Nov 2, 2016

@xzyfer , regarding build failure, can you make sure that installed node is in the path? Also if you want to use same command prompt, you might want to call <node_chakracore_installation_path>\nodevars.bat which will set right environment variables.

kunalspathak commented Nov 2, 2016

@xzyfer , regarding build failure, can you make sure that installed node is in the path? Also if you want to use same command prompt, you might want to call <node_chakracore_installation_path>\nodevars.bat which will set right environment variables.

@xzyfer

This comment has been minimized.

Show comment
Hide comment
@xzyfer

xzyfer Nov 2, 2016

Contributor

can you make sure that installed node is in the path
@kunalspathak sorry for not being clear, my issue was that I don't know how to make an MSI file do those things :)

@nschonni aha this looks like what I was after. I took a look around that repo but got caught of the disparity between those function names and the ones in their docs.

Contributor

xzyfer commented Nov 2, 2016

can you make sure that installed node is in the path
@kunalspathak sorry for not being clear, my issue was that I don't know how to make an MSI file do those things :)

@nschonni aha this looks like what I was after. I took a look around that repo but got caught of the disparity between those function names and the ones in their docs.

@kunalspathak

This comment has been minimized.

Show comment
Hide comment
@kunalspathak

kunalspathak Nov 2, 2016

@nschonni , there is extra customization that we did for node-chakracore installer in our private fork. You can diff below files for node vs. node-chakracore. It forces to use installed sdks/libs/headers rather than downloading from nodejs.org.

  • <node_installation_path>\node_modules\npm\node_modules\node-gyp\lib\configure.js

image

  • <node_installation_path>\node_modules\npm\node_modules\node-gyp\addon.gypi

image

kunalspathak commented Nov 2, 2016

@nschonni , there is extra customization that we did for node-chakracore installer in our private fork. You can diff below files for node vs. node-chakracore. It forces to use installed sdks/libs/headers rather than downloading from nodejs.org.

  • <node_installation_path>\node_modules\npm\node_modules\node-gyp\lib\configure.js

image

  • <node_installation_path>\node_modules\npm\node_modules\node-gyp\addon.gypi

image

@nschonni

This comment has been minimized.

Show comment
Hide comment
@nschonni

nschonni Nov 2, 2016

Contributor

I'll see if I can figure out what would be needed in the module to get AppVeyor to just natively support the install

Contributor

nschonni commented Nov 2, 2016

I'll see if I can figure out what would be needed in the module to get AppVeyor to just natively support the install

@xzyfer

xzyfer approved these changes Nov 3, 2016

@xzyfer

This comment has been minimized.

Show comment
Hide comment
@xzyfer

xzyfer Nov 3, 2016

Contributor

I've updated this PR with the required AppVeyor config, as well tidying up the node-gyp resolution.

All that's missing is some jsdoc comments for the new functions we I think this is done.

Contributor

xzyfer commented Nov 3, 2016

I've updated this PR with the required AppVeyor config, as well tidying up the node-gyp resolution.

All that's missing is some jsdoc comments for the new functions we I think this is done.

Show outdated Hide outdated appveyor.yml Outdated
Show outdated Hide outdated scripts/build.js Outdated
Show outdated Hide outdated lib/extensions.js Outdated
@kunalspathak

This comment has been minimized.

Show comment
Hide comment
@kunalspathak

kunalspathak Nov 3, 2016

@xzyfer , I noticed some issues and fixed in recent commits. If they look good, feel free to merge it.

kunalspathak commented Nov 3, 2016

@xzyfer , I noticed some issues and fixed in recent commits. If they look good, feel free to merge it.

@matthargett

This comment has been minimized.

Show comment
Hide comment
@matthargett

matthargett Nov 3, 2016

/cc @rdy -- this fix allows node-chakracore to run pivotal-cf/react-starter with all tests passing (on Windows, anyway -- didn't test Linux/MacOS), resolving nodejs/node-chakracore#136 . There is a crash when the test runner exits, but that also happens with nodejs-v8 on Windows.

matthargett commented Nov 3, 2016

/cc @rdy -- this fix allows node-chakracore to run pivotal-cf/react-starter with all tests passing (on Windows, anyway -- didn't test Linux/MacOS), resolving nodejs/node-chakracore#136 . There is a crash when the test runner exits, but that also happens with nodejs-v8 on Windows.

Show outdated Hide outdated appveyor.yml Outdated
@kunalspathak

This comment has been minimized.

Show comment
Hide comment
@kunalspathak

kunalspathak Jul 11, 2017

@nschonni - Is there a way to trigger the build again? Seems like appveyor.yml picked the old version of nvs.

kunalspathak commented Jul 11, 2017

@nschonni - Is there a way to trigger the build again? Seems like appveyor.yml picked the old version of nvs.

@nschonni

This comment has been minimized.

Show comment
Hide comment
@nschonni

nschonni Jul 11, 2017

Contributor
Contributor

nschonni commented Jul 11, 2017

@kunalspathak

This comment has been minimized.

Show comment
Hide comment
@kunalspathak

kunalspathak Jul 11, 2017

@nschonni - That was it. Fixed it.

kunalspathak commented Jul 11, 2017

@nschonni - That was it. Fixed it.

@xzyfer

This comment has been minimized.

Show comment
Hide comment
@xzyfer

xzyfer Jul 12, 2017

Contributor

Thanks again for all your work on this @kunalspathak and @nschonni

Contributor

xzyfer commented Jul 12, 2017

Thanks again for all your work on this @kunalspathak and @nschonni

@nschonni

LGTM, just a few wrap up minor questions

*
* @api private
*/
function resolveNodeGyp() {

This comment has been minimized.

@nschonni

nschonni Jul 13, 2017

Contributor

Do we still need this now that the version is bumped to 3.6?

@nschonni

nschonni Jul 13, 2017

Contributor

Do we still need this now that the version is bumped to 3.6?

This comment has been minimized.

@kunalspathak

kunalspathak Jul 13, 2017

No and that's why i removed my changes in 5021dff . I just kept the resolution of node-gyp in separate function for easy readability.

@kunalspathak

kunalspathak Jul 13, 2017

No and that's why i removed my changes in 5021dff . I just kept the resolution of node-gyp in separate function for easy readability.

This comment has been minimized.

@nschonni

nschonni Jul 13, 2017

Contributor

👍 that makes sense

@nschonni

nschonni Jul 13, 2017

Contributor

👍 that makes sense

Show outdated Hide outdated appveyor.yml Outdated
@kunalspathak

This comment has been minimized.

Show comment
Hide comment
@kunalspathak

kunalspathak Jul 13, 2017

@nschonni - I have fixed chakracore version to chakracore/8.

kunalspathak commented Jul 13, 2017

@nschonni - I have fixed chakracore version to chakracore/8.

@kunalspathak

This comment has been minimized.

Show comment
Hide comment
@kunalspathak

kunalspathak Jul 17, 2017

Thanks @nschonni and @xzyfer so far for shaping the PR. Let me know if you need anything else to merge this PR.

kunalspathak commented Jul 17, 2017

Thanks @nschonni and @xzyfer so far for shaping the PR. Let me know if you need anything else to merge this PR.

@saper

This comment has been minimized.

Show comment
Hide comment
@saper

saper Jul 19, 2017

Member

What are the process.versions.module values for chakracore engines? How often do they change? How many shall we support?

Member

saper commented Jul 19, 2017

What are the process.versions.module values for chakracore engines? How often do they change? How many shall we support?

@kunalspathak

This comment has been minimized.

Show comment
Hide comment
@kunalspathak

kunalspathak Jul 19, 2017

@saper - did you mean to say process.versions.modules. If yes, it is 57 currently and has same value as node-v8. We don't control it and it will be set from upstream node that we inherit.

kunalspathak commented Jul 19, 2017

@saper - did you mean to say process.versions.modules. If yes, it is 57 currently and has same value as node-v8. We don't control it and it will be set from upstream node that we inherit.

@saper

This comment has been minimized.

Show comment
Hide comment
@saper

saper Jul 19, 2017

Member

Thanks. This is mainly used to denote changes in the V8 API, I thought Chakra might have come up with something different?

Member

saper commented Jul 19, 2017

Thanks. This is mainly used to denote changes in the V8 API, I thought Chakra might have come up with something different?

@saper

This comment has been minimized.

Show comment
Hide comment
@saper

saper Jul 19, 2017

Member

In other words: suppose I have downloaded a chakracore node-sass binary module 57 today. How would I know I need a new one, say, 6 months from now? Is ABI stability guaranteed? We have lots of problems with users forgetting to update their modules.

Member

saper commented Jul 19, 2017

In other words: suppose I have downloaded a chakracore node-sass binary module 57 today. How would I know I need a new one, say, 6 months from now? Is ABI stability guaranteed? We have lots of problems with users forgetting to update their modules.

@kunalspathak

This comment has been minimized.

Show comment
Hide comment
@kunalspathak

kunalspathak Jul 19, 2017

It should work similar to way it works with node-v8. So lets say in future node.js 10.X , the modules version was updated to say 79, when we release node-chakracore from 10.X branch, it will have same module versions i.e. 79 because to release that we would have shimmed required v8 APIs . Does that make sense ?

kunalspathak commented Jul 19, 2017

It should work similar to way it works with node-v8. So lets say in future node.js 10.X , the modules version was updated to say 79, when we release node-chakracore from 10.X branch, it will have same module versions i.e. 79 because to release that we would have shimmed required v8 APIs . Does that make sense ?

@saper

This comment has been minimized.

Show comment
Hide comment
@saper

saper Jul 19, 2017

Member

Do I understand this correctly @kunalspathak that chakracore is V8-API compatible? If so, what is breaking ABI compatibility, so that the existing binaries cannot be used?

Member

saper commented Jul 19, 2017

Do I understand this correctly @kunalspathak that chakracore is V8-API compatible? If so, what is breaking ABI compatibility, so that the existing binaries cannot be used?

@kunalspathak

This comment has been minimized.

Show comment
Hide comment
@kunalspathak

kunalspathak Jul 19, 2017

chakracore is V8-API compatible

Yes. In order for node-chakracore to work we shim all the V8 APIs that node or a native module calls into.

kunalspathak commented Jul 19, 2017

chakracore is V8-API compatible

Yes. In order for node-chakracore to work we shim all the V8 APIs that node or a native module calls into.

@saper

This comment has been minimized.

Show comment
Hide comment
@saper

saper Jul 19, 2017

Member

ok, that solves the API problem, i.e. module compiled by hand should generally work.

How do we ensure ABI compatibility between modules?

Examples on situations where ABI may work:

  • You are bumping ChakraCore engine version (for example from 1.5.2 to 1.5.3). It may or may not break the ABI - both ChakraCore engine versions are attached to NODE_MODULE_VERSION 57.
  • You decide to do some changes in the chakrashims: for example you decide to allow more than 8 local variables on the stack and therefore bump kOnStackLocals to something else, which will almost probably break ABI.

Even today, will node-sass binding.module compiled with ChakraCore 1.5.2 work with 1.5.3? Is the reverse true?

(I cannot get ChakraCore to build, so I cannot test at the moment).

This is a major concern from my side - if we are to offer binary module downloads, ABI stability must be guaranteed.

Member

saper commented Jul 19, 2017

ok, that solves the API problem, i.e. module compiled by hand should generally work.

How do we ensure ABI compatibility between modules?

Examples on situations where ABI may work:

  • You are bumping ChakraCore engine version (for example from 1.5.2 to 1.5.3). It may or may not break the ABI - both ChakraCore engine versions are attached to NODE_MODULE_VERSION 57.
  • You decide to do some changes in the chakrashims: for example you decide to allow more than 8 local variables on the stack and therefore bump kOnStackLocals to something else, which will almost probably break ABI.

Even today, will node-sass binding.module compiled with ChakraCore 1.5.2 work with 1.5.3? Is the reverse true?

(I cannot get ChakraCore to build, so I cannot test at the moment).

This is a major concern from my side - if we are to offer binary module downloads, ABI stability must be guaranteed.

@kunalspathak

This comment has been minimized.

Show comment
Hide comment
@kunalspathak

kunalspathak Jul 19, 2017

This is a major concern from my side - if we are to offer binary module downloads, ABI stability must be guaranteed.

That is a valid concern. However ABI compatibility is guaranteed by chakrashim and not chakracore. So even if we switch chakracore versions, as long as chakrashim is v8 API compatible, it should just work.

for example you decide to allow more than 8 local variables on the stack and therefore bump kOnStackLocals to something else

I am not sure how this will break the compatibility. This is purely chakrashim's optimization that is nothing to do with breaking compatibility.

kunalspathak commented Jul 19, 2017

This is a major concern from my side - if we are to offer binary module downloads, ABI stability must be guaranteed.

That is a valid concern. However ABI compatibility is guaranteed by chakrashim and not chakracore. So even if we switch chakracore versions, as long as chakrashim is v8 API compatible, it should just work.

for example you decide to allow more than 8 local variables on the stack and therefore bump kOnStackLocals to something else

I am not sure how this will break the compatibility. This is purely chakrashim's optimization that is nothing to do with breaking compatibility.

@saper

This comment has been minimized.

Show comment
Hide comment
@saper

saper Jul 19, 2017

Member

If my binding is compiled with kOnStackLocals = 8 and v8handlescope.cc coming from the updated ChakraCore uses, say, 16, couldn't that lead to a mismatch in the size of HandleScope ?

In general: can we have something that will be bumped whenever one of the deps/ exposed to the modules changes?

Member

saper commented Jul 19, 2017

If my binding is compiled with kOnStackLocals = 8 and v8handlescope.cc coming from the updated ChakraCore uses, say, 16, couldn't that lead to a mismatch in the size of HandleScope ?

In general: can we have something that will be bumped whenever one of the deps/ exposed to the modules changes?

@kunalspathak

This comment has been minimized.

Show comment
Hide comment
@kunalspathak

kunalspathak Jul 19, 2017

In general: can we have something that will be bumped whenever one of the deps/ exposed to the modules changes?

We could have that, but the plan is not to diverge chakrashim from v8 headers unless v8 changes come from upstream. So in that case, version will only get bumped when upstream bump the version.

kunalspathak commented Jul 19, 2017

In general: can we have something that will be bumped whenever one of the deps/ exposed to the modules changes?

We could have that, but the plan is not to diverge chakrashim from v8 headers unless v8 changes come from upstream. So in that case, version will only get bumped when upstream bump the version.

@xzyfer

This comment has been minimized.

Show comment
Hide comment
@xzyfer

xzyfer Jul 20, 2017

Contributor

I touched on some of these concerns earlier. IIRC we greatly reduce risk from ABI changes by adopting N-API which is very close on our road map, and may land in the same release as this.

Contributor

xzyfer commented Jul 20, 2017

I touched on some of these concerns earlier. IIRC we greatly reduce risk from ABI changes by adopting N-API which is very close on our road map, and may land in the same release as this.

@kunalspathak

This comment has been minimized.

Show comment
Hide comment
@kunalspathak

kunalspathak Jul 21, 2017

@xzyfer , do you have an ETA on when this can land?

kunalspathak commented Jul 21, 2017

@xzyfer , do you have an ETA on when this can land?

@saper

This comment has been minimized.

Show comment
Hide comment
@saper

saper Jul 22, 2017

Member

This is a volunteer-driven project, so no ETAs here. I am concerned with releasing something quick now and worry about future compatibility "later".

Member

saper commented Jul 22, 2017

This is a volunteer-driven project, so no ETAs here. I am concerned with releasing something quick now and worry about future compatibility "later".

@kunalspathak

This comment has been minimized.

Show comment
Hide comment
@kunalspathak

kunalspathak Jul 22, 2017

Sorry @saper , I didn't mean to pressurize to land this PR prematurely. Its been a while the PR is open and I thought I addressed all the concerns. Let me know if there are any other issues that you want me to address and I will be happy to fix them.

kunalspathak commented Jul 22, 2017

Sorry @saper , I didn't mean to pressurize to land this PR prematurely. Its been a while the PR is open and I thought I addressed all the concerns. Let me know if there are any other issues that you want me to address and I will be happy to fix them.

@davej

This comment has been minimized.

Show comment
Hide comment
@davej

davej Aug 30, 2017

@kunalspathak Would you consider maintaining a fork and publishing to npm? Would love to use this as many of my frontend projects are constantly requiring re-builds when I upgrade node. Usually node-sass is the only native dep so would love to use this.

davej commented Aug 30, 2017

@kunalspathak Would you consider maintaining a fork and publishing to npm? Would love to use this as many of my frontend projects are constantly requiring re-builds when I upgrade node. Usually node-sass is the only native dep so would love to use this.

@kunalspathak

This comment has been minimized.

Show comment
Hide comment
@kunalspathak

kunalspathak Aug 30, 2017

Thanks for asking @davej , but I am not sure if I understand your problem. This PR simply adds a support to build and work with node-chakracore. When you upgrade node, you might still need to rebuild.

kunalspathak commented Aug 30, 2017

Thanks for asking @davej , but I am not sure if I understand your problem. This PR simply adds a support to build and work with node-chakracore. When you upgrade node, you might still need to rebuild.

@davej

This comment has been minimized.

Show comment
Hide comment
@davej

davej Aug 30, 2017

@kunalspathak sorry I skimmed the issue and saw a mention of N-API and assumed that's what the PR was about.

davej commented Aug 30, 2017

@kunalspathak sorry I skimmed the issue and saw a mention of N-API and assumed that's what the PR was about.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment