I followed https://www.npmjs.com/package/jsonpath. Tried a way to include external js file, but no luck.
import jsonPath worked after -
import * as jsonPath from 'jsonpath/jsonpath';
JsonPath plush also worked JSONPath-plus which is same as of Jsonpath. I have following coding snippet which is working for me-
install JSONPath-plus
npm install jsonpath-plus
angular.json file
"scripts": [
"node_modules/jsonpath-plus/dist/index-umd.js",
"src/assets/js/jsonpath.js"
]
jsonpath.js have following code -
function jsonPath() {
return JSONPath;
}
Now use this function in ts file with declaring it like below -
declare const jsonPath: any;
// use it like
jsonPath().JSONPath(path, json);
Related
In some popular NodeJS libraries, e.g. ssh2 or node-pty, there is natively compiled code as part of the library.
Creating the project with
vue create my-project
vue add electron-builder
yarn add ssh2
then importing and using ssh2's Client in the background process results in following errors during
electron:build
ERROR Failed to compile with 1 errors 5:29:10 PM
error in ./node_modules/cpu-features/build/Release/cpufeatures.node
Module parse failed: Unexpected character '�' (1:0)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
(Source code omitted for this binary file)
# ./node_modules/cpu-features/lib/index.js 1:16-60
# ./node_modules/ssh2/lib/protocol/constants.js
# ./node_modules/ssh2/lib/client.js
# ./node_modules/ssh2/lib/index.js
...
This error occurs with many other libs or transitive dependencies and the reason for it is absence of native-ext-loader on Webpack chain. I understand why it is not included by default, and I would like to see what is the best way to add it.
One solution I found is this:
Add yarn add -D native-ext-loader (my version is 2.3.0 and electron is at 13.x)
Adjust vue.config.js and add the chainWebpackMainProcess like this:
const path = require('path')
module.exports = {
pluginOptions: {
electronBuilder: {
builderOptions: {
// options placed here will be merged with default
mac: {
target: 'dmg',
icon: 'build/icon.icns',
asar: true
}
},
preload: 'src/preload.ts',
chainWebpackMainProcess(config) {
config.module
.rule("node")
.test(/\.node$/)
.use("native-ext-loader")
.loader("native-ext-loader")
.options(
process.env.NODE_ENV === "development"
? {
rewritePath: path.resolve(__dirname, "native"),
}
: {}
)
}
}
}
}
Both, electron:build and electron:serve are now working and ssh2 client is happily delivering the stdout to renderer via ipcMain. Not sure it is the most elegant way of solving it, though.
I'm using the css-loader and style-loader with Webpack. As expected, style tags get added to the head of the document, but there doesn't seem to be any way to determine which import led to a given style tag. My understanding is that the css-loader is responsible for reading the actual css files from the import, so it seems like something that should be configured with that loader. I can't find anything that would make that possible based on these docs though: https://webpack.js.org/loaders/css-loader/
I imagine there's existing plugins and loaders to handle the need I mentioned, but I couldn't find any. I was able to get this custom loader working:
In projectRoot/web_loaders/css-module-path-includer.js:
module.exports = function (content) {
return [
`/* resource: ${this.resource} */`,
content
].join('\n')
}
Updates to webpack.config.js:
module.exports = {
...
resolveLoader: {
modules: [ 'node_modules', path.resolve(__dirname, "./web_loaders") ],
},
rules: [
{
test: /\.css$/i,
use: [
'style-loader',
'css-loader',
'css-module-path-includer'
],
}
]
}
which gives you:
and then you can use something like this to track down which module in your source ultimately led to the import:
run
npx webpack --profile --json > stats.json
there was output before and after the actual json in the output that I had to edit. There's probably an argument that results in just the json being printed.
in find_dependency_root.py
import json
import sys
stats = json.loads(open('stats.json').read())
dependency = sys.argv[1]
visited = {}
dependency_chain = [dependency]
while True:
module = next(module for module in stats['modules']
if dependency in str(module['id']))
# try to account for circular dependencies
if module['issuerId'] != 0 and dependency not in visited:
visited[dependency] = True
dependency = module['issuerId']
dependency_chain.insert(0, dependency)
else:
print('\n'.join(dependency_chain))
break
python3 find_dependency_root.py antd/lib/popover/style/index.css
./src/main/resources/static/js/Root.tsx
...
./node_modules/antd/lib/popconfirm/style/css.js
./node_modules/antd/lib/popover/style/css.js
antd/lib/popover/style/index.css
I might be mixing up concepts, but I'd read that it's possible to get TestCafe to recognize variables of the form process.env.MY_COOL_VARIABLE. Also for my Vue.js frontend (built using Vue-CLI, which uses dotenv under the hood), I found I could make a file in .env.test for test values like so:
VUE_APP_MY_COOL_VARIABLE
which I would then access in my test code like so:
test('my fixture', async (t) => {
...
await t
.click(mySelector.find('.div').withText(process.env.VUE_APP_MY_COOL_VARIABLE));
...
}
However, I get the following error:
"text" argument is expected to be a string or a regular expression, but it was undefined.
Seems like my environment variables aren't getting picked up. I build my code like so: vue-cli-service build --mode test.
TestCafe doesn't provide support for .env files out of the box. You can create a test file that will require the dotenv module and load your configuration file:
// enable-dotenv.test.js
require('dotenv').config({ path: '.my.env' });
testcafe chrome enable-dotenv.test.js tests/
Here's how I solved my issue. When debugging, I did a console.log of process.env and noticed that the variable that vue recognizes wasn't visible during testcafe's run. From our package.json:
"test:ui:run": "VUE_APP_MY_COOL_VARIABLE=ui-test yarn build:test && testcafe -a ../ui-test-server.sh chrome",
Also this bit of javascript is run by both the test and mainline code, so I had to use a conditional.
import * as dotenv from 'dotenv';
if (process.env.npm_package_scripts_test_ui_run) { // are we running a testcafe script
dotenv.config({ path: '.env.test' });
}
Have you tried process.env[VUE_APP_MY_COOL_VARIABLE]? It's worth noting that everything in dotenv comes back as a string so you may need to do the casting yourself. For example:
function getEnvVariableValue(envVariable: string) {
// Cast to boolean
if (envVariableValue.toUpperCase() === "TRUE") {
return true;
} else if (envVariableValue.toUpperCase() === "FALSE") {
return false;
// Cast to number
} else if (!isNaN(Number(envVariableValue))) {
return Number(envVariableValue);
} else {
return envVariableValue;
}
}
You can also try creating a .env file in the root folder to see if it picks it that way. I use dotenv in my project directly by including it in the package.json as a dependency and it works this way.
I am having trouble with scss module imports when I am running flow check. I have tried out various approaches including
.flowconfig
[options]
module.name_mapper.extension='scss' -> '<PROJECT_ROOT>/flow-typed/stub/css-module.js'
and I have
// #flow
type CSSModule = { [key: string]: string }
const emptyCSSModule: CSSModule = {}
export default emptyCSSModule
in the css-module.js. Do you know why it's happening?
I believe I had a similar issue when trying to use .styl files for stylus.
You might be able to solve this issue by doing the following which had worked for me:
Remove the css-module.js file.
Remove that module.name_mapper.extension line that you have in your .flowconfig
Add the following to the [options] in your .flowconfig:
module.file_ext=.js
module.file_ext=.jsx
module.file_ext=.json
module.file_ext=.scss
I am working on the Angular 2.0-Meteor tutorial and on step 20 "Handling Files with CollectionFS" I am getting an error.
"Cannot find module 'meteor/jalik:ufs'." I have tried removing and adding jalik:ufs and calling meteor reset but this error seems to persist.
I get the error when trying to run the sample code included before Step 21 as well.
It is related with typings. Right now I don't think there is an existing typings for this package.
So you can write your own typings.
Or use the temporary way to remove the warning:
Remove import { UploadFS } from 'meteor/jalik:ufs';. Then add declare const UploadFS: any; in any file.
Tutorial was updated in between:
See Point 21.22 Declare meteor/jalik:
Link
declare module "meteor/jalik:ufs" {
interface Uploader {
start: () => void;
}
interface UploadFS {
Uploader: (options: any) => Uploader;
}
export var UploadFS;
}