It helps quite a lot to have a LSP server running. The LSP I know that works with it uses Clang, and it expects a compile_commands.json on the root of the code. To generate this just run npm install then run:
node-gyp -- configure -f=compile_commands_json
This will generate both Debug/compile_commands.json and Release/compile_commands.json. Just select one and move to the root, like mv Release/compile_commands.json .
So, for everyone wanting to help on this migration:
We have to uncomment everything that's on here: https://github.com/pulsar-edit/superstring/compare/master...pulsar-edit:superstring:napi#diff-0d6aa7470314ca774fd7e07f67b35ecd3045fe5cb3a0e5c99f48bae897905d32
It helps quite a lot to have a LSP server running. The LSP I know that works with it uses Clang, and it expects a
compile_commands.json
on the root of the code. To generate this just runnpm install
then run:This will generate both
Debug/compile_commands.json
andRelease/compile_commands.json
. Just select one and move to the root, likemv Release/compile_commands.json .
...Wrapped
classes can receive arbitrary data. This basically do not work with Napi, so we need to generate aNapi::External<arbitrary-data>
and pass this to the contructor. There's an example onPointWrapper
class: https://github.com/pulsar-edit/superstring/compare/master...pulsar-edit:superstring:napi#diff-ca393bd63cb0ed098a1eee4542120db434961ff60b65c22b2476c15eb954451aR52-R54Other trick is that Nan have lots of
Unwrap()
andWrap()
. These are not necessary on Napi (Napi is saner in this sense)nop
. This is No-op, so I don't see any reason to keep them. I'm removing it completely, just so people know :)