I'm trying to use the linkurious library (a sigma fork), which provides a "main": "dist/sigma.require.js" (in the package.json). this allows me to do:
var sigma = require('linkurious');
however, the plugins are not included so I have to require them separately. the problem is that the plugins rely on the sigma variable being available in the global scope. so I've shimmed things as follows (from the package.json):
"browser": {
"sigma": "./node_modules/linkurious/dist/sigma.js",
"linkurious/plugins": "./node_modules/linkurious/dist/plugins.js"
},
"browserify-shim": {
"sigma": {"exports": "sigma"},
"linkurious/plugins": { "depends": [ "sigma" ] }
},
"browserify": {
"transform": [ "browserify-shim" ]
},
which, when run in a browser doesn't generate errors during inclusion of the plugins (I gather this means the global variable is available) but references to the plugins fail (as if they failed to attach themselves, or attached themselves to a non-global variable).
I'm using grunt-browserify to run the process where I have it configured like this (from the Gruntfile.js):
grunt.initConfig({
browserify: {
libs: {
files: { 'inc.js': ['index.js'] },
},
}
});
I've attached a little project to this issue with the minimal required code to demonstrate the problem in the hopes that someone else can replicate/figure out. unpack, type npm install; npm start and run a browser against http://localhost:8002/ to see the issue.
thanks in advance,
ekkis
sigma.zip
- edit I -
incidentally, bendrucker at the git repo (see: https://github.com/thlorenz/browserify-shim/issues/215) suggests I need to do a global transform. It's been explained to me that shimming doesn't work on node_modules files and for those I need a global transform. this doesn't make much sense to me as the whole point of shimming is that you don't own the code you're shimming. in any case, bendrucker pointed me to this other SO post where the question is posed but no answers are provided.
help?
Related
Original Question
How do I correctly "configure" the (unified, remark, remark-lint) remark-lint-no-undefined-references plugin/rule "allow" option for use with the remark-cli?
My goal is to configure the rule to ignore the Azure DevOps Wiki's non-standard table of contents tag, [[_TOC_]]. My simplified setup entails:
All packages globally installed. Probably not relevant.
A parent folder in which I have:
A package.json file.
A Test folder containing just the one Test.md file whose only content is this one line [[_TOC_]].
From a command prompt whose working folder is the aforementioned parent folder, I execute:
remark Test
Default Operation
The default operation, i.e. just the plugin/rule specified in the package.json file, returns the expected warning. This is, presumably, due to the non-standard tag, [[_TOC_]]. This is the warning I wish to turn off.
package.json (default)
{
"remarkConfig": {
"plugins": [
"remark-lint-no-undefined-references"
]
}
}
Execution and Expected Warning (default)
C:\..>remark Test
test\Test.md
1:1-1:10 warning Found reference to undefined definition no-undefined-references remark-lint
1:2-1:9 warning Found reference to undefined definition no-undefined-references remark-lint
‼ 2 warnings
What I've tried
I've tried to adapt remark-lint-no-undefined-references API example and Configuration, 'rules can be configured in one standard way' to my package.json file. After much trial and error, I've ended up with this seemingly valid json:
package.json
{
"remarkConfig": {
"plugins": [
"remark-lint-no-undefined-references", [1, {
"allow": ["[[_TOC_]]"]
}]
]
}
}
The Online JSON Viewer and JSONLint indicate it's valid JSON. However, remark-cli yields this error. Other variations yielded different errors. I am stumped.
C:\..>
Test\Test.md
1:1 error Error: Cannot parse file `package.json`
Expected preset, not `1`
at Error (file:///C:/Users/scott.welker/AppData/Roaming/npm/node_modules/remark-cli/node_modules/fault/index.js:39:12)
at file:///C:/Users/scott.welker/AppData/Roaming/npm/node_modules/remark-cli/node_modules/unified-engine/lib/find-up.js:190:15
at done (file:///C:/Users/scott.welker/AppData/Roaming/npm/node_modules/remark-cli/node_modules/trough/index.js:145:7)
× 1 error
Update 03/14/2022
I've made some progress thanks to a bit of help on GitHub Issue (#210). However, that was not the right avenue and it is closed. My issue remains.
A Few Things are Apparent
My initially inferred JSON, package.json, is incorrect. See Hacked my JSON below.
I failed to appreciate how the non-standard Azure DevOps Wiki table of contents tag, [[_TOC_]], is interpreted. See Tag Interpretation (console-log) following.
My inferred package.json seemingly remains incorrect. See My JSON Must Still be Wrong below.
Hacked my JSON
To overcome ...Error: Cannot parse file 'package.json', Expected preset, not '1' I hacked my file so that I now have the following. This change overcomes the error and enables me to continue but it is still seemingly incorrect. See My JSON Must Still be Wrong.
package.json file
{
"remarkConfig": {
"plugins": [
"remark-lint-no-undefined-references", {
"allow": ["_TOC_", "[_TOC_]"]
}
]
}
}
Tag Interpretation (console.log)
After hacking my JSON, I added a recommended console.log (..\npm\node_modules\remark-lint-no-undefined-references\index.js) of id. This reveals that the linting interprets the table of contents tag as two separate bits of concerning markdown, _TOC_ and [_TOC_]. I did not appreciate this. However, the findings below suggest this may not be a problem. See My JSON Must Still be Wrong.
remark-cli
C:\..>remark Test
Id: _TOC_
Id: [_TOC_]
Test\Test.md
1:1-1:10 warning Found reference to undefined definition no-undefined-references remark-lint
1:2-1:9 warning Found reference to undefined definition no-undefined-references remark-lint
‼ 2 warnings
My JSON Must Still be Wrong
Referring to another location in the source here (line 126), when I replace that const allow definition with this hard-coded declaration, const allow = new Set(["_TOC_", "[_TOC_]"]), I get the desired behavior. E.g.:
remark-cli
C:\...>remark Test
Test\Test.md: no issues found
Next Steps:
See whether I can forgo the package.json and instead use pure javascript. Either my JSON is incorrect or it isn't being interpreted correctly.
Continue to futz with the JSON. What I've inferred may well be wrong.
The following guess also fails to suppress the unwanted warnings:
package.json
{
"remarkConfig": {
"plugins": [
"remark-lint-no-undefined-references", [{
"allow": ["_TOC_", "[_TOC_]"]
}]
]
}
}
Update 03/28/2022
CAUTION!
While the setup in this update is valid, the Test.js example code is flawed. See 03/30/2022 Update below.
Following up on "Next Step, see whether I can forgo the package.json and instead use pure javascript."
I seem to have made it work except it suppresses all warnings, not just the few (two) that I am targeting. More development and testing is needed.
New Setup
A new parent Node.js application folder in which I have:
Opted to re-install all packages, and some new ones, but not globally (this time):
npm install to-vfile
npm install vfile-reporter
npm install remark
npm install remark-lint
npm install remark-lint-no-undefined-references
The node_modules folder. Created and populated by npm installs (dependencies).
A package.json file. Created and populated by npm installs.
A package-lock.json file. Created and populated by npm installs.
A copy of the same Test folder containing just the one Test.md file whose only content is this one line [[_TOC_]].
From a command prompt whose working folder is the aforementioned parent folder, I execute my new node/javascript code:
node Test.js See following. Code comments illustrate the unexpected suppression of all warnings, even those not targeted.
Test.js
WARNING! This code is incorrect. See the 03/30/2022 Update below.
import {reporter} from 'vfile-reporter'
import {remark} from 'remark'
import remarkLint from 'remark-lint'
import remarkLintNoUndefinedReferences from 'remark-lint-no-undefined-references'
import {read} from 'to-vfile'
main()
async function main() {
const file = await remark()
.use(remarkLint)
// This useage results in the expected warnings, '...Found reference to undefined definition...'
.use(remarkLintNoUndefinedReferences)
// This usage suppresses the warnings, as desired. However, note the next usage.
//.use(remarkLintNoUndefinedReferences[ { allow: [ '_TOC_', '[_TOC_]' ] }])
// This usage also suppresses the warning but it shoud not have done so.
//.use(remarkLintNoUndefinedReferences[ { allow: [ '...', '…' ] }])
// This usage (and related tests) seem to illustrate that anything in the allowed array suppresses all warnings.
//.use(remarkLintNoUndefinedReferences[ { allow: [ '' ] }])
.process(await read('.\\Test\\Test.md'))
console.error(reporter(file))
}
Update 03/30/2022
Here is a corrected Test.js file where my invalid usages are commented out, marked WRONG, and the two correct usages are marked GOOD. The final usage corrects mistakes made in my 03/28/2022 update. I now have a working javascript version. I just need to adapt this known working version to the remark-cli's package.json file. Getting very close.
I arrived at this CORRECT, working usage through trial and error. My trial and error was aided by adding console.log() statements to the ..\remark-lint-no-undefined-references\index.js source and tweaking my javascript code as guided by repeated re-reading of the remark-lint Configure section.
Test.js
import {reporter} from 'vfile-reporter'
import {remark} from 'remark'
import remarkLint from 'remark-lint'
import remarkLintNoUndefinedReferences from 'remark-lint-no-undefined-references'
import {read} from 'to-vfile'
main()
async function main() {
const file = await remark()
.use(remarkLint)
// WRONG: This usage seems to suppress the warnings, as desired. However, note the next usage.
//.use(remarkLintNoUndefinedReferences[ { allow: [ '_TOC_', '[_TOC_]' ] }])
// WRONG: This usage also seems to supresses the warnings but, it shoud not have done so.
//.use(remarkLintNoUndefinedReferences[ { allow: [ '...', '…' ] }])
// WRONG: This usage (and related tests) seem to illustrate that anything in the allowed array suppresses all warnings.
//.use(remarkLintNoUndefinedReferences[ { allow: [ '' ] }])
// GOOD: This usage results in the expected warnings, '...Found reference to undefined definition...'
//.use(remarkLintNoUndefinedReferences)
// GOOD: This usage seems to be correct!!
.use(remarkLintNoUndefinedReferences, [1, { allow: [ '_TOC_', '[_TOC_]' ] }])
.process(await read('.\\Test\\Test.md'))
console.error(reporter(file))
}
Execution and Output
C:\..>node Test.js
DEBUG remarkTest: allow contains 2 items.
DEBUG remarkTest Id: '_TOC_'
DEBUG remarkTest Id: '[_TOC_]'
.\Test\Test.md: no issues found
The package.json below correctly "configures" the remark-lint-no-undefined-references plugin/rule "allow" option for use with remark-cli.
Note: I also transitioned away from globally installed packages out of an unsubstantiated concern that they might have contributed to my problem. See Multiple globally installed presets and plugins don’t work #165. This transition accounts for the added package.json "dependencies". See following.
package.json
I arrived at this by working from my 03/30/2022 update and futzing with varying syntax illustrated in the Unified Engine, Configuration, Schema section.
Again, my goal is to configure the rule to ignore the Azure DevOps Wiki's non-standard table of contents tag, [[_TOC_]].
{
"remarkConfig": {
"plugins": {
"remark-lint-no-undefined-references": { "allow":[ "_TOC_", "[_TOC_]" ] }
}
},
"dependencies": {
"remark": "^14.0.2",
"remark-lint": "^9.1.1",
"remark-lint-no-undefined-references": "^4.1.1"
}
}
Execution and Output
Note: my debug console.log(...) remains in place.
C:\..>remark Test
DEBUG remarkCLITest: allow contains 2 items.
Test\Test.md: no issues found
I am building a snowpack app right now, and I would like to import socket.io client in the frontend (For intellisense and offline dev testing). However, socket.io only exports the backend materials when using import ... from 'socket.io'.
Normally, I use
import { io } from 'socket.io/client-dist/socket.io.js';
Which gets all the correct files and exports, however, when building with snowpack I get this error:
Package exports for 'C:\dev\JS\Node+Browser\foo\node_modules\socket.io' do not define a './client-dist/socket.io.js' subpath
Which fails the build, stopping everything.
Right now, my snowpack.config is really bare bones:
module.exports = {
buildOptions: {
out: 'dist/client'
},
mount: {
"src/client": "/"
}
}
All of the rest of my modules run fine, because they are all imported with only import ... from 'module-name. I understand what the error is saying, but I cant find anything online or thing of anything to solve it. Does anyone know how to fix this?
NOTE: This is a "hacky" fix that I think is messy and can not be used for larger projects.
I patched this by editing the package.json of the socket.io package (In node_modules) to use a temporary export alias that was exactly the same as the real directory path:
node_modules/socket.io/package.json
"exports": {
".": [
{
"require": "./dist/index.js",
"import": "./wrapper.mjs"
},
"./src/index.js"
],
"./client-dist/socket.io": "./client-dist/socket.io.js",
"path-to-other-modules": "same-path"
},
TL;DR How can I create an alias for a local yarn workspace dependency?
I've tried yarn workspaces before and never succeeded, and I'm giving it another try.
I've set "workspaces": ["packages/*"] in package.json.
For each package, I decided to use the naming convention #-/package-name to prevent naming conflicts and without worrying about having namespaces for internal packages.
When adding packages as dependencies, I've been following a style where I use an interface name for resolution, but point that towards a concrete implementation. This is what I did before using yarn workspaces:
"dependencies": {
"my-interface-name": "file:some/path/to/packages/some-concrete-implementation"
}
This is basically to allow what I like to call compile-time static dependency injection. And it also means each package can individually name their interface dependencies appropriately to their need and to prevent naming conflicts.
However, I can't figure out how to accomplish this with yarn workspaces. How do I create an alias for my yarn workspaces package #-/some-concrete-implementation called my-interface-name?
What I've already tried with no success:
Defining the dependency like "my-interface-name": "#-/some-concrete-implementation"} - for some reason this causes yarn to look for #-/some-concrete-implementation on the npm registry instead of in the local workspace
I've also tried to use the workspace protocol: "my-interface-name": "workspace:#-/some-concrete-implementation"} but it still looks for the package on the npm registry!
What I haven't yet tried and could work but removes benefits of using yarn workspaces in the first place:
"dependencies": {"my-interface-name": "file:../../node_modules/#-/some-concrete-implementation"}"
Have you seen the resolutions package.json key? Is it what you need?
I've used it for aliasing/overriding external packages but the example in the docs shows it working with local packages.
Resolutions
Allows you to override a version of a particular nested dependency. See the Selective Versions Resolutions RFC for the full spec.
{
"resolutions": {
"transitive-package-1": "0.0.29",
"transitive-package-2": "file:./local-forks/transitive-package-2",
"dependencies-package-1/transitive-package-3": "^2.1.1"
}
}
From the RFC:
"**/a" denotes all the nested dependencies a of the project.
"a" is an alias for **/a (for retro-compatibility, see below, and because if it wasn't such an alias, it wouldn't mean anything as it would represent one of the non-nested project dependencies, which can't be overridden as explained below).
So, I believe the rule you need is:
"**/my-interface-name": "file:some/path/to/packages/some-concrete-implementation"
// OR equivalent
"my-interface-name": "file:some/path/to/packages/some-concrete-implementation"
I believe it works in the package's package.json. Worst case you can hoist it to the workspace root and make the rule specific to the workspace e.g. "a/b".
The workspace: alias protocol (available in pnpm too) seems the direction to take.
I've also tried to use the workspace protocol: "my-interface-name": "workspace:#-/some-concrete-implementation"} but it still looks for the package on the npm registry!
Be sure to have yarn 3 installed, otherwise you'll run into weird issues.
Note that the syntax of "my-interface-name": "workspace:#-/some-concrete-implementation" looks incorrect.
It should be "#xxx/some-concrete-implementation": "workspace:*", assuming the name of linked the package is "name": "#xxx/some-concrete-implementation".
With this in mind you don't even need to create a specific #-/name. With workspace protocol, yarn will ensure it's never downloaded from npm. It becomes an internal workspace dependency.
PS:
Yarn 3 installation
Generally a simple yarn set version 3.0.2 && yarn plugin import workspace-tools) will work.
To avoid pnp current limitation, check the generated config .yarnrc.yml and ensure nmLinker is set to 'node-modules'
# Yarn 2+ supports pnp or regular node_modules installs. Use node-modules one.
nodeLinker: node-modules
plugins:
- path: .yarn/plugins/#yarnpkg/plugin-workspace-tools.cjs
spec: "#yarnpkg/plugin-workspace-tools"
yarnPath: .yarn/releases/yarn-3.0.2.cjs
PS: you might want to add this to .gitignore too
.yarn/*
!.yarn/patches
!.yarn/releases
!.yarn/plugins
!.yarn/sdks
!.yarn/versions
.pnp.*
Run a yarn install just after.
About package.json's
Like you did, the root package.json will define the workspace paths:
{
"name": "monorepo",
"workspaces": [
"packages/*" // Enable package discovery in packages/* directory.
],
// ...
"devDependencies": {
"husky": "7.0.2", // Only what's needed for monorepo management
}
In your app packages/app/package.json
{
"name": "my-app",
"devDependencies": {
"#types/node": "16.10.1",
//...
},
"dependencies": {
// Assuming the name of packages/shared is "#your-org/some-concrete-implementation",
// we explicitly declare the dependency on it through
// workspace: alias (package-manager perspective)
"#your-org/some-concrete-implementation": "workspace:*",
}
}
You consumed package should declare the same name
{
"name": "#your-org/some-concrete-implementation",
}
Bonus: Typescript aliases
If your project is written in ts, you can even replicate your paths through
typescript path mapping. It will allow to include the files just as is (no prior compilation needed).
Following your example, just edit a ./packages/xxx/tsconfig.json in this way
{
"compilerOptions": {
// here baseUrl is set at ./src (good practice), can
// be set to '.'
"baseUrl": "./src",
"paths": {
// Declare deps here (keep them in sync with what
// you defined in the package.json)
// PS: path are relative to baseUrl
"#your-org/some-concrete-implementation/*": ["../../some-concrete-implementation/src/*"],
// if you have a barrel in ui-lib
"#your-org/some-concrete-implementation": ["../../some-concrete-implementation/src/index"],
}
},
}
PS: for non typescript: babel/plugin-module-resolver can be used in a similar manner.
I need to include a library that is present on github, but is not well-packaged; using Duo.js
At the moment of writing I am using the following to achieve what I desire:
bower
gulp
main-bower-files
Bower just downloades the library.
Gulp, with main-bower-files are useful to override the single package options and setup a so-called "main file" that I can build.
Example:
gulp.task('copy-libs', function () {
return gulp.src(bowerFiles({ env: 'development' }))
.pipe(gulp.dest('build/libs/'));
});
bower.json file:
"dependencies": {
"cash": "sudo-js/cash",
"bootstrap": "~3.3.2",
"delorean": "~0.8.7",
"react": "~0.12.2"
},
"overrides": {
"cash": {
"main": {
"development": "build/debug/cash.js"
}
}
}
}
How can i achieve this with duojs?
The documentation is quite thin regarding libraries that does not ship with a valid component.json
You can specify the path to an entry file for your lib. It won't be as clean as just specifying user/repo, but it'll get the job done.
For example, when including Twitter Bootstrap from twbs/bootstrap
require('twbs/bootstrap#v3.3.2:dist/js/bootstrap.js');
// repo: twbs/bootstrap
// version/tag: v3.3.2
// path: dist/js/bootstrap.js
Unfortunately, this doesn't work out-of-the-box since it assumes you have the jQuery global... so you need to add this above the previous line.
jQuery = require('components/jquery'); // leave out `var` so it becomes a global
This includes jQuery from the wonderful components project. (they package up popular libs so they can be consumed by various package managers.
Also, it turns out there is a components/bootstrap that is properly packaged with a component.json.
So, you can actually make bootstrap work with the following:
jQuery = require('components/jquery');
require('components/bootstrap');
For the other libraries that aren't as common, you can use the process mentioned first to specify the path to the right JS/CSS file. (ie: user/repo#version:path)
I'm trying to install behat + mink (on kohana framework, not symfony, I'm putting behat into the modules folder - I'm writting this just in case, but I guess that's not what causes my problem).
I am having the same search.feature file as it is in behat documentation, I'm changing features/bootstrap class into the:
<?php
use Behat\Behat\Context\ClosuredContextInterface,
Behat\Behat\Context\TranslatedContextInterface,
Behat\Behat\Context\BehatContext,
Behat\Behat\Exception\PendingException;
use Behat\Gherkin\Node\PyStringNode,
Behat\Gherkin\Node\TableNode;
use Behat\MinkExtension\Context\MinkContext;
/**
* Features context.
*/
class FeatureContext extends MinkContext
{
}
And when I type "behat" in the CLI I get the following error: Call to a member function getSession() on a non object in .....RawMinkContext.php on line 80.
I've read somewhere that it's the behat.yml file which causes this error. I think the right thing to do is to create new behat.yml file in the root of the installed behat folder and put this code inside:
default:
extensions:
Behat\MinkExtension\Extension:
base_url: http://wikipedia.org
goutte: ~
selenium2: ~
paths:
features: features
bootstrap: features/bootstrap
annotations:
paths:
features: features/annotations
closures:
paths:
features: features/closures
But of couse it gives me the same error. I've tried a lot of configurations: copying only extensions part, changing default into context, copying the same content into three other behat.yml files (vendor/behat/behat, and vendor/behat/monk, and vendor/behat/monk-ententions) - none works.
Can someone tell me what's the right way to set this? Maybe someone here also had problems with that...
BTW. When I installed behat withough goutte, only with selenium2 driver, I was getting errors that goutte is not installed. But when I installed it with goutte, I was getting errors that there's no fabpot/goutte directory (or fapbot/, I don't remember, but I guess it was the first one :D), so I deleted everything and reinstalled behat with the following composer.json file, maybe this also has something to do with this error:
{
"name": "behat/mink-browserkit-driver",
"description": "Symfony2 BrowserKit driver for Mink framework",
"keywords": ["Symfony2", "testing", "browser"],
"homepage": "http://mink.behat.org/",
"type": "mink-driver",
"license": "MIT",
"authors": [
{
"name": "Konstantin Kudryashov",
"email": "ever.zet#gmail.com",
"homepage": "http://everzet.com"
}
],
"require": {
"php": ">=5.3.1",
"symfony/browser-kit": ">=2.0.0,<2.2.0",
"symfony/dom-crawler": ">=2.0.0,<2.2.0",
"behat/behat": "2.4.*#stable",
"behat/mink": "1.4.*#stable",
"behat/mink-extension": "*",
"behat/mink-goutte-driver": "*",
"behat/mink-selenium2-driver": "*"
},
"minimum-stability": "dev",
"autoload": {
"psr-0": {
"Behat\\Mink\\Driver": "src/"
}
},
"config": {
"bin-dir": "bin/"
}
}
The recommended way to install Behat+Mink for anything, not just Kohana, is via Composer. See http://docs.behat.org/quick_intro.html for instructions. The autoload clause you have in your composer.json is not required.
As for your modules attempt, KO3.2 does not yet have the ability to load PSR-0 and so putting it in modules will not allow it to be loaded correctly.
Don't randomly copy your behat.yml - you only need one copy in your project root. If you are worried, you can explicitly load your behat.yml via bin/behat -c /path/to/behat.yml
With your composer.json set up correctly to have mink dependencies, you can then just do bin/behat -dl to verify mink works.
You can then do bin/behat --init to create your features filestructure.
This will create a FeatureContext which overrides Mink's definitions, so add
require_once __DIR__.'/../../vendor/autoload.php';
and change the class definition to:
class FeatureContext extends Behat\MinkExtension\Context\MinkContext
in your features/bootstrap/FeatureContext.php file.
Everything should work as expected now. I recently did a Behat+Mink+KO3 setup, feel free to see how I did it here: https://github.com/Moult/Eadrax/commit/b5dd813c92b82aea29eea13b5a30bae170aa57e6