I am trying to find the location of the source file for an internal module called by process.binding('base_filter') in "base-filter.js".
It's a react/electron app using electron-prebuilt.
This script is located in:
+-- electron-prebuilt
| +-- dist
| +-- resources
| +-- electron.asar
| +-- filtering
| +-- api
| +-- exports
| +-- base-filter.js
I've searched exhaustively for solutions, I've tried:
var natives = process.binding('natives');
for (var key in natives) {
console.log(key);
}
From How to obtain a list of all available Node.js modules?
Which didn't show the module.
I've tried:
node.js Internals: How can I find out where `process.binding('eval')` gets defined?
What is `process.binding('fs')` in `fs.js`?
I've tried batch searching every single file in the code-base for mention of "base_filter" with no success, i also tried searching my PCs appdata and user files thinking it might be caching somewhere, no success.
I'm wringing my hair out over this, I just need to be able to trace where it's being loaded from so i can edit it/ fix any problems.
I would appreciate any help, thank you.
Related
I want to initialize a monorepo, and then initialize apps inside the packages folder. I found a bunch of examples of how to do this. But, what I want to achieve is, I want to keep all the node_modules at the root level.
--monorepo
|--node_modules
|--packages
| |--create-react-app-1
| | |--src
| | |--{...rest}
| |--create-react-app-2
| | |--src
| | |--{...rest}
|--package.json
So, all the node_modules are at the root level and all the packages are using them from the root level. All the dependencies and dev-dependencies are listed in the root level package.json.
I want to use yarn as the package manager as well.
How I can achieve this?
I have a new angular2 project that was built using the standard file structure described in the quickstart. I am attempting to build an API gateway and have spring-boot host my application, however I haven't been able to configure boot to use the /dist directory in my project where the generated sources are created. The project structure is as follows:
project
|--dist
|--node_modules
|--src
| |--app
| |--assets
| |--main
| | |--java
| | |--resources
| | | |--config
| | |--webapp
| | | |--WEB-INF
I would like to use the default /dist directory so that I can still use npm/webpack for continuous development on the UI.
I tried configuring the static resources directory like so:
spring.resources.staticLocations: /dist
But this doesn't seem to be working.
I created a resource handler to point directly to the dist directory:
#Configuration
public class WebMvcConfiguration extends WebMvcConfigurerAdapter {
#Override
public void addResourceHandlers(final ResourceHandlerRegistry registry) {
String currentPath = new File("./").getAbsolutePath();
currentPath = "file:///" + currentPath;
registry.addResourceHandler("/**").addResourceLocations(currentPath + "/dist/");
}
}
This solves part of the problem but now my root URL ('/') no longer maps to index.html.
Is there an easier/better way to configure spring-boot to find the /dist project directory? Should my project structure change? I would really like to get all of these pieces working together cleanly.
Spring Boot will automatically add static web resources
located within any of the following directories:
/META-INF/resources/
/resources/
/static/
/public/
The folders are relative to src/main/resources
If you put index.html like below, then spring can serve your file
without any configuration.
src/main/resources/META-INF/resources/index.html
src/main/resources/resources/index.html
src/main/resources/static/index.html
src/main/resources/public/index.html
I took #chrylis advice and pointed the destination directory for the webpack build to build/dist (using Gradle).
I avoided putting the generated sources in /resources/** because eventually this will get built into a .war and deployed to an enterprise application server -- I didn't want a lot of include/exclude logic in my build to support this. Plus the build directory seemed a more logical place for the generated .js source.
My project structure now looks like this:
project
|--build
| |--dist
| |--...
|--node_modules
|--src
| |--app
| |--assets
| |--main
| | |--java
| | |--resources
| | | |--config
| | |--webapp
| | | |--WEB-INF
I eliminated the WebMvcConfigurerAdapter and configured the static resources to point to my dist directory in build:
spring.resources.static-locations: "file:./build/dist/"
I'm now able to run Webpack, Spring-Boot or deploy to my application server with the same source and very little configuration overhead.
I wrote a very simple local module to manage a few lines of localized text.
It uses node's require to load the language files, but I'm having trouble with paths, most likely.
I'm getting the Cannot find module error.
File structure
.
+-- local_modules
| +-- lang
| | +-- package.json
| | +-- index.js
+-- locale
| +-- en.js
| +-- de.coffee
+-- init.js
+-- index.coffee
+-- package.json
Relevant module code
Should require the file if it is not already loaded.
join = require('path').join;
_config.path = './locale';
lang = 'en';
_locales = {};
if(!_locales[lang]){
_locales[lang] = require(join(_config.path, lang));
}
Every file in the locale directory is a typical Node.js module, for example en.js:
module.exports = {
test: 'Hello World!'
};
The local module exports a function(req, res, next){}, which is used as Express middleware and is supposed
to attach the required object with localized strings onto res.locals, however, I'm seeing Cannot find module 'locale/en' error.
I've tried to manually add the .js extensions (but that shouldn't be neccessary as far as I know).
I have also tried different variations on the path, such as locale or /locale.
The module is called in index.coffee.
App is launched using init.js, which contains the following:
require('coffee-script/register');
require('./index');
Maybe it's just that the module is a .js (and the module itself doesn't have CoffeeScript as a dependency) so it can not load a .coffee file? Although CoffeeScript should be registered globally, or am I wrong? Either way, it doesn't work with the .js file either, so I guess it has something to do with paths.
path.join() also normalizes the created path, which (probably) means the ./ part was always removed, and what remained was a relative path.
Instead, when path.resolve() is used, it creates an absolute path, which is what is needed in this case.
I've started to play around with using NPM Scripts and BabelJS to transpile my ES2015 AngularJS project. The problem is that the concatenated order is not correct and causes nomod errors.
Given this directory structure:
MyApp
+- src
| +- dashboard
| | +- search-bar
| | | +- search-bar.directive.js
| | | +- search-bar.service.js
| | | +- search-bar.spec.js
| | +- dashboard.module.js
+- dist
| +- js
| | +- dashboard.js
Ideally, dashboard.module.js should be the first file because that is where the actual dashboard module is created, followed by everything in /search-bar which actually doesn't require any order at all. The search bar is a feature/component, not a new module and is all part of dashboard.
The problem seems to be that simply running BabelJS will just concatenate all the files together using the same structure as the filesystem does.
babel ./src/dashboard/**/*.js -o ./dist/js/dashboard.js
There are also weird things when messing with the wildcards to try make sure all files are captured.
How can I process dashboard.js first before any of the other components?
It turns out you can specify many globs as input files.
Try using this command:
babel ./src/dashboard/*.js ./src/dashboard/**/ -o ./dist/js/dashboard.js
This will first process any .js immediately inside of /dashboard followed by the rest of the directory.
Gotcha: This will only really work as long as you only have the one file inside of the /dashboard root. If you were to add dashboard.config.js or any other file, then this would process those files in that filesystem order. Unfortunately, dashboard.config.js comes before dashboard.js so your problem will continue. :(
Also, if you have other files in /dashboard root or you have other kinds of .js that you don't want to be included, you'll need to ignore them.
Try:
babel ./src/dashboard/**/*.js ./src/dashboard/**/ --ignore *.spec.js --ignore *.conf.js -o ./dist/js/dashboard.js
This will put things in the right order and also skip any karma.config.js or search-bar.service.spec.js files you may put in there. I assume that you don't want those actually being used in production.
I am building a Node app that returns results for a search using a Google Custom Search Engine(CSE).
I am going to separate the part of the app that sends the request to Google and returns the results into a module.
I use dotenv already in the app to store MongoDB credentials and the app's URL.
I also want to use dotenv in the module to store the Google CSE ID and the API key for the CSE.
I want my module to work independently of the main app but also to use the main app's dotenv file when it's a module.
Currently my module structure looks like this:
module
|
+-- node_modules
| |
| \-- dotenv
| |
| \-- (dotenv module's files....)
|
+-- .env
|
\-- index.js
This works perfectly on its own. The .env file stores the required environment variables and I can access them in the index.js file by requiring the dotenv module.
When included in the main app the structure looks like this:
app
|
+-- node_modules
| |
| +-- dotenv
| | |
| | \-- (dotenv module's files....)
| |
| \-- my_google_search_module
| |
| +-- node_modules
| | |
| | +-- dotenv
| | |
| | \-- (dotenv module's files...)
| |
| \-- index.js
|
+-- .env
|
\-- index.js
This also works. I store all the environment variables in the main app's .env file and by requiring dotenv in the app's index.js I can access those variables. Plus, the "my_google_search_module" seems to be pulling its required variables from the .env file in the root of the app. There is no .env file in the module.
My question is am I doing this the right way?
I have researched this further and can confirm that the module's .env is pulling the required environment variables from the app's .env file.
I believe this section from the dotenv readme, though not exactly related, verifies that -
https://www.npmjs.com/package/dotenv#what-happens-to-environment-variables-that-were-already-set
We will never modify any environment variables that have already been
set. In particular, if there is a variable in your .env file which
collides with one that already exists in your environment, then that
variable will be skipped. This behavior allows you to override all
.env configurations with a machine-specific environment, although it
is not recommended.
Yes, you are doing in a right way. There must be a single .env file in a whole project. But there is a trick to include it in the different directory structure.
For example:
Your index.js file is in /app/src, your .env file is in /app. Your index.js file has this
dotenv.config({path: "../.env"});
You could also use dotenv.config({path: path.join(__dirname, "../.env")});
for node projects, i would suggest to use npm package dotenv. You can find details on how to use it. do not forget to include require('dotenv').config() at the start of your project file, say index.js.
Now you can use .env contents anywhere you need. For example i want my server port to be 4000 which i define in .env as PORT=4000. Now, to use .env variables anywhere, simply provide variable name in suffix such as process.env.PORT. That is it. Though i am late on this post, hope this could be of any help.