search

nodejs / js-native-api-test

Node.js js-native-api-test suite, externalized so that it can be used to test Node-API implementations outside of Node.js
MIT License
7 stars 10 forks source link

Bootstrap this project with v10.10.0 #3

Closed yorkie closed 3 years ago

yorkie commented 5 years ago

@mhdawson I have pulled the source of Node.js v10.10.0 as our first test suite to land:

Refs: https://github.com/nodejs/napi-test-suite/issues/2

mhdawson commented 5 years ago

If we are going to have multiple versions of the test suite, I suggest that we add the files under a version, maybe instead or src

v3/src

for the N-API version number. I think versioning makes more sense based on N-API version as opposed to the node version. All versions of Node.js which support N-API version 3 should be able to build/pass the test suite for N-API version 3.

mhdawson commented 5 years ago

Thinking a bit about the work to split out N-API into the JS and Node specific components we may want to put it into

V3/napi/src

so that we could later also have V3/jsapi/src or something like that.

mhdawson commented 5 years ago

Left my comments so far, did not look at most of the files as I assume they are just a copy from node core.

@yorkie have you figured out how to take what is in this PR and then build/run the test suite with shadow-node. If so adding the files/instructions for that to

building/shadownode

might make sense.

yorkie commented 5 years ago

If we are going to have multiple versions of the test suite, I suggest that we add the files under a version.

What I proposed at #2 is to use NPM to version different tests, so user could use NTS by:

$ npm i @nodejs/napi-test-suite@9.0.0
$ npm i @nodejs/napi-test-suite@10.0.0
$ npm i @nodejs/napi-test-suite@11.0.0

Does this look good to you?

have you figured out how to take what is in this PR and then build/run the test suite with shadow-node. If so adding the files/instructions for that to binding/shadownode

As I have proposed at last answer, for example at ShadowNode, I would add a dependency @nodejs/napi-test-suite with the version ^10.0.0, and ShadowNode could build via NPM.

legendecas commented 5 years ago

If we are going to have multiple versions of the test suite, I suggest that we add the files under a version.

What I proposed at #2 is to use NPM to version different tests, so user could use NTS by:

$ npm i @nodejs/napi-test-suite@9.0.0
$ npm i @nodejs/napi-test-suite@10.0.0
$ npm i @nodejs/napi-test-suite@11.0.0

Does this look good to you?

have you figured out how to take what is in this PR and then build/run the test suite with shadow-node. If so adding the files/instructions for that to binding/shadownode

As I have proposed at last answer, for example at ShadowNode, I would add a dependency @nodejs/napi-test-suite with the version ^10.0.0, and ShadowNode could build via NPM.

AFAIK, n-api has its own versioning alone with node core, so the versioning of napi-test-suite might be following n-api's rather than node core's.

yorkie commented 5 years ago

AFAIK, n-api has its own versioning alone with node core, so the versioning of napi-test-suite might be following n-api's rather than node core's.

I see, will change the version to the N-API's.

gabrielschulhof commented 5 years ago

I don't think we need different subdirectories for different versions of N-API, because the versions are cumulative. node_api.h includes all versions of N-API, including the experimental features.

mhdawson commented 5 years ago

@gabrielschulhof that's true provided we can tell the test suite what version of N-API to test and it excludes building/running tests for functions that are greater than that level. I know we have that in node-addon-api but I can't remember off the top of my head if we have it in the core testing. Will need to look.

yorkie commented 5 years ago

Versioning is necessary for implementors, because developers needs to know what N-API version is supported. But I'm -1 on using sub directories, too, both the git and npm are the version management tools, I will tend to use those to manage the different versions.

legendecas commented 5 years ago

both the git and npm are the version management tools, I will tend to use those to manage the different versions.

@yorkie If the napi-test-suite is distributed to npm in different versions following N-API version, implementors have to install multiple versions of napi-test-suite to test compatibilities across N-API versions. If a test command line option might be a better choice?

mhdawson commented 5 years ago

Sounds like the best approach is a single copy of the test suite, adding flags that can be used to limit which tests are run (assuming that is practical) and then potentially also tagging/branching if necessary for releases.

yorkie commented 5 years ago

Ok, now agreed with @legendecas and @mhdawson, we tend to use tag, namely GitHub release, so we also need to provide a tool(or on NPM) to download the given NTS version(s), I will make changes ASAP, thanks all for suggestions :)

mhdawson commented 3 years ago

@yorkie, there have been a lot of changes since this PR. There is a renewed effort outlined in https://github.com/nodejs/js-native-api-test/issues/7. I'm going to close this PR as I think we should populate with a more up to date version of the tests.

Please let me know if you think that was not the right thing to do.