Skip to content
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

CommonJS and npm integration #16

Open
jacobrask opened this issue Jun 10, 2014 · 6 comments · May be fixed by #54
Open

CommonJS and npm integration #16

jacobrask opened this issue Jun 10, 2014 · 6 comments · May be fixed by #54

Comments

@jacobrask
Copy link

Allowing require() in addition to the import macro would enable you to use a bunch of modules from the npmjs repository in your CocoaScript code.

If a depended on module is using Node APIs it would obviously not run in a CocoaScript environment, but a lot of the modules in npm are simple cross-platform JavaScript libraries like underscore.js.

CocoaScript modules could be submitted to npm, and you have a package manager for free.

@NickolasHu
Copy link

Is there any way to use CommonJS or npm modules in CocoaScript for now? @jacobrask

@ccgus
Copy link
Owner

ccgus commented Jan 15, 2016

No there isn't.

@mathieudutour
Copy link
Contributor

@ccgus
Copy link
Owner

ccgus commented Nov 25, 2016

Neat

@mathieudutour
Copy link
Contributor

mathieudutour commented Jan 24, 2018

@ccgus I worked on this a bit and have a POC working in Sketch, going to be released in 49.

Basically, I added a require global. It is kind of the counterpart of the @import syntax of CocoaScript but for working with node packages: you need to use module.exports to expose what you want, it doesn’t pollute the global scope, it is dynamic, etc.

For now, it has a very simple resolver algorithm:

  • I maintain a list of core modules that Sketch ships with. For now, there is only sketch.
  • If the path starts with a ., it’s a relative path and I’m looking for a js file starting from the command file.

So it doesn’t handle nested relative require very well (it's working if you have your require in the top level; but not if they are in a function, it will look for the package starting from where the function is executed), nor looking for a node_modules folder.

In parallel, I started to create a few packages to mirror the NodeJS API: fs to replace the use of NSFileManager, child_process for NSTask, etc.. The goal is multiple:

  • provide an easy to use API: the NodeJS API has been created with JavaScript in mind, callbacks make a lot more sense than error pointers, obj-c delegates are a pain to use, etc..
  • Those APIs are the basic building blocks that you need pretty much all the time. If we manage to control their quality (well tested, correct error handling, nice async usage, argument sanitization, etc.), we can hopefully raise the quality of the entire plugin ecosystem.
  • The docs are already done :)
  • Complete NodeJS compatibility! Imagine being able to install any npm packages without worrying whether it’s using some node API!

Later, when those packages are finished, we will probably ship them with Sketch directly.

I understand that it's vision that might not match the one you have for CocoaScript so I preferred asking here if it's worth for me creating a PR to upstream this or not.

@ccgus
Copy link
Owner

ccgus commented Jan 25, 2018

Yep, make the PR. This would be pretty cool to have.

@mathieudutour mathieudutour linked a pull request Jan 26, 2018 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants