Error: Cannot find module '../../modules/core.regexp.escape'

[danmichaelo]

First, thanks for creating this – a very interesting project!

I installed the package using npm install primo-explore-dom --save-dev.

Since I'm using browserify, the package wasn't included automagically, so I tried adding a

require('primo-explore-dom/js/primo-explore-dom');

but when running gulp I got:

Error: Cannot find module '../../modules/core.regexp.escape' from '/path/to/primo-explore-devenv/primo-explore/custom/UIO/node_modules/primo-explore-dom/js'

When looking at the primo-explore-dom.js file, I notice that it indeed requires core-js and regenerator-runtime, but these are not declared in package.json. Should they?

Also, I don't really understand how custom.js is built, and where the ../../modules/core.regexp.escape path in custom.js:34 comes from. Notice that it uses "modules" rather than "node_modules" – rather weird. Perhaps you can add a "Contribute" or "Develop" section to the README where you document how to build this project?

[mehmetc]

Hi Dan,
If you are using the browserify flag then just clone primo-explore-dom into your VIEW_CODE/js directory or create a symlink to it.

import Primo from './primo-explore-dom/js/primo'

//make Primo public
window.Primo = Primo;

That is what we do in our CENTRAL_PACKAGE

Let me know if you still have questions.

Mehmet

[danmichaelo]

Thanks, Mehmet, I can confirm that that works.

But I would much prefer to keep dependencies out of my source code. Wouldn't it work if you added the rest of the .js files to the npm package, not just custom.js?

Also, I'm still interested in how you generate custom.js :)

[mehmetc]

Sorry, for not being able to get back sooner. It is not a real dependency or should I say it is not a real module it is a primo-explore package. It was done this way because in the normal mode of the development environment all the files get bluntly concatenated into 1 file -> the custom.js file. In the "browserify" mode it is a different story we have packagers, loaders etc. So, in a moment of weakness I worked around it by symlinking to the directory. But you are absolutely right this is not the way. I'll first need to think on how to fix this. Should it still be a library running in it's own context or should you be able to load the artifacts you need in your code.

import User from '@primo/user'

Both have their advantages and disadvantages I guess.
Anyhow I'm interested in what you think and thanks for pointing this out.

Thanks
Mehmet

[danmichaelo]

No prob!

My only other dependency so far is lodash, which allows me to do

import get from 'lodash/get';

which is great since it means I don't have to include the whole library. In the same way, I think it would be great if you could import single components from this library, like you suggest:

import User from '@primo/user'

Btw. what is the @ sign doing?

Unfortunately I'm not familiar enough with Node packaging to be able to provide much practical help, but I guess you would have to distribute both the source files (for the Browserify users) and the custom.js (for the “concatters”)?

[mehmetc]

the @ sign defines a scope. I'll see what I can do. I'm favoring the browserify or other bundler solution today. If you have time and are interested in helping out we could do a small brainstorm call to see how to proceed ...