loynoir/example-jest-config-esm
loynoir/python-fire
loynoir/ssdb
loynoir/expandUser.js
loynoir/ExpandUser.go
loynoir/defer.py
loynoir issue comment yarnpkg/berry
@merceyz OK, forget about preinstall and install.
npm postinstall output
"^1.0.22"
1.0.23
pnpm postinstall output
"^1.0.22"
1.0.23
yarnBerry postinstall output
"1.0.23"
1.0.23
Both npm and pnpm update package.json version after postinstall.
But yarnBerry update package.json version before postinstall,
which makes a update function useless.
function update(fromVer, toVer) {
// babel transform `fromVer` to `toVer`
}
loynoir issue yarnpkg/berry
Actually, yarn berry update repo's package.json BEFORE dependency preinstall script.
Causing different behavior compared to both npm and pnpm when running script
Given
repo has{
"devDependencies": {
"foo": "1.0.22"
}
}
foo has script preinstall, install, postinstall, to detect update from which version# update from
jq \
".devDependencies[\"${name}\"]" \
"${INIT_CWD}"/package.json
# update to
echo "${npm_package_version}"
foo from 1.0.22 to 1.0.23
yarn berry output
"1.0.23"
1.0.23
"1.0.23"
1.0.23
"1.0.23"
1.0.23
npm output
"^1.0.22"
1.0.23
"^1.0.22"
1.0.23
"^1.0.22"
1.0.23
pnpm output
"1.0.22"
1.0.23
"1.0.22"
1.0.23
"1.0.22"
1.0.23
Node: 16.14.2
Yarn: 3.2.0
No response
loynoir issue comment yarnpkg/berry
With re-usable global cache enabled, can not perform a offline install.
$ env \
YARN_ENABLE_GLOBAL_CACHE=true \
YARN_NPM_REGISTRY_SERVER=http://127.0.0.1:1234 \
yarn
no error
➤ YN0001: │ RequestError: connect ECONNREFUSED 127.0.0.1:1234
Node: 16.14.2
Yarn: 3.2.0
No response
@arcanis
Isn't unreachable enought? 😅
$ env \
YARN_ENABLE_GLOBAL_CACHE=true \
YARN_NPM_REGISTRY_SERVER=https://unreachable \
yarn
Anyway, full reproduction
loynoir issue yarnpkg/berry
With re-usable global cache enabled, can not perform a offline install.
$ env \
YARN_ENABLE_GLOBAL_CACHE=true \
YARN_NPM_REGISTRY_SERVER=http://127.0.0.1:1234 \
yarn
no error
➤ YN0001: │ RequestError: connect ECONNREFUSED 127.0.0.1:1234
Node: 16.14.2
Yarn: 3.2.0
No response
loynoir issue sindresorhus/type-fest
import type { JsonValue, PackageJson } from "type-fest"
function fn(j: JsonValue) {
console.log(j)
}
const pj: PackageJson = {}
fn(pj)
$ ts --noEmit
# (no error)
$ ts --noEmit
src/index.ts(8,4): error TS2345: Argument of type 'PackageJson' is not assignable to parameter of type 'JsonValue'.
Type 'PackageJson' is not assignable to type 'JsonObject'.
Index signature for type 'string' is missing in type 'PackageJson'.
loynoir issue prettier/prettier
Prettier 2.6.2 Playground link
# Options (if any):
Input:
var o = { a: a, b: b, c: c };
export { foo as foo }
Output:
var o = { a: a, b: b, c: c };
export { foo as foo }
Expected behavior:
var o = { a, b, c };
export { foo }
Given
{ X }
When
<F2> twice to rename referenceBecomes
{ Y: Y } or { Y as Y }.Would be nice if prettier can make them shorthand again, as short-handify after rename-reference is not part of language server protocol.
https://babeljs.io/docs/en/babel-plugin-transform-shorthand-properties
loynoir issue comment esm-dev/esm.sh
Currently, a http only server is not working, unless hostname is hardcoded localhost.
Add a place holder to allow customize http only hostname
are you saying something like
--http-only-hostname=localhost
Ah, yes 😃
loynoir issue comment esm-dev/esm.sh
@ije Maybe consider using someeslint rules, prevent some future mistaks?
loynoir issue comment eslint/eslint
My shareable config uses rules from an external plugin and I would like to make it a dependency so the user doesn't have to manually install the plugin manually. I couldn't find any docs on this, but it doesn't seem to work, so I'll assume it's not currently supported.
module.js:338
throw err;
^
Error: Cannot find module 'eslint-plugin-no-use-extend-native'
at Function.Module._resolveFilename (module.js:336:15)
at Function.Module._load (module.js:278:25)
at Module.require (module.js:365:17)
at require (module.js:384:17)
at /usr/local/lib/node_modules/eslint/lib/cli-engine.js:106:26
at Array.forEach (native)
at loadPlugins (/usr/local/lib/node_modules/eslint/lib/cli-engine.js:97:21)
at processText (/usr/local/lib/node_modules/eslint/lib/cli-engine.js:182:5)
at processFile (/usr/local/lib/node_modules/eslint/lib/cli-engine.js:224:12)
at /usr/local/lib/node_modules/eslint/lib/cli-engine.js:391:26
I assume it's because you only try to load the plugin when the config is finished merging.
Other shareable configs that depend on a plugin instructs the users to manually install the plugin too and they have it in peerDependencies. I find this sub-optimal though and I don't want the users to have to care what plugins my config uses internally.
The whole point of shareable configs is to minimize boilerplate and overhead, so this would be a welcome improvement.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
Was using pnpm, this was never a problem with public-hoist-pattern[]=*eslint*.
But, recently I try yarn berry.
Does any one know what's the workaround for yarn berry, the hoist way, or any way to let yarn berry auto install peer dependency?
loynoir issue esm-dev/esm.sh
Arrow function don't have arguments
(()=>{arguments})()
Uncaught ReferenceError: arguments is not defined
(function(){arguments})()
OK
loynoir issue esm-dev/esm.sh
Currently, a http only server is not working, unless hostname is hardcoded localhost.
Add a place holder to allow customize http only hostname
loynoir forked esm-dev/esm.sh
loynoir/esm.sh
Current
{
"devDependencies": {
"@foo/bar": "file:.yalc/@foo/bar",
"a": "1.2.3",
"b": "1.2.3"
}
}
Expected, with version, more symmetric, and seems more reproducible
{
"devDependencies": {
"@foo/bar": "file:.yalc/@foo/[email protected]",
"a": "1.2.3",
"b": "1.2.3"
}
}
loynoir issue yarnpkg/berry
Describe the user story Was not a yarn berry user.
Try a pnpm repo on a remote machine.
Try bi-sync way first, but give up as it's sync is not blocking.
Then the fuse way, but the large node_modules get things very very slow.
For example
require('benny')
Then I remember yarn berry, awesome!
So, decided to use yarn berry in some situations.
But, I gonna ask some things, seems but found in document.
I use typescript, and ESM. Using other PM, I can run .mts by
$ node --loader esbuild-node-loader ./foobar.mts
How can I do that if i use yarn berry?
node_modules, what can I do if I want to quick modify source of a dependency?Describe the solution you'd like
Describe the drawbacks of your solution
Describe alternatives you've considered
loynoir issue comment pnpm/pnpm
(I'm not sure if this issue is related to pnpm or npm)
6.31.0
"foo": "workspace:*"
pnpm publish -r
Workspace references have been replaced with an actual version in the published package.
The published package still contains "workspace:*" as version, making it not installable.
pnpm pack the version is being applied
https://github.com/pnpm/pnpm/issues/4438
i used workaround, add .files field to package.json
loynoir issue comment esm-dev/esm.sh
Hello @ije, been a little while. I'm getting back into this project a little more, and realizing that it would be a lot easier to make it work for use cases that I'm trying to, if the core functionality was a library that you can pass objects to rather than a server with configuration options.
That would keep the implementations and drivers light in the library, and open free server version of the project.
What do you think?
How would it help me and where is this coming from? The more I get into the AWS linkage, the more I think a library would feel better in this separation of concerns.
Hi, guys. How can you install esm.sh binary?
My not freq used esm.sh docker image now takes 1.5G.
loynoir issue egoist/tsup
index.mts
const answer: number = 42
export { answer }
$ tsup index.mts
Unexpected token (Note that you need plugins to import files that are not JavaScript)
1: const answer: number = 42
^
2: export { answer }
loynoir issue comment node-fetch/node-fetch
THIS IS A PROPOSAL
As explained in #1226, the fact that node-fetch v3.0.0-beta.10 is now pure ESM cause multiple problems with existing codebases.
In JavaScript codebases, we need to use the async import() which can create a lot of changes.
In TypeScript codebases (with cjs module mode), it is impossible to use node-fetch anymore.
I think that ESM is the future but it is not as stable as we think and it is not ready to be used everywhere.
The best way to ensure that all existing codebases can migrate to v3 is to provide both cjs and esm versions of this module.
For this, I introduced esbuild which can transpile ESM to CJS and also can bundle the package.
You can say: "node does not need packages to be bundled", which is true. However, bundling is a good practice to reduce the module loading time, disk operations, memory footprint, etc. It can also be used to bundle internal dependencies and so reduce the npm dependency tree (reduce install time, disk operations, memory footprint, npm hell, etc.).
What is the purpose of this pull request?
What changes did you make? (provide an overview)
Which issue (if any) does this pull request address?
Is there anything you'd like reviewers to know?
In this implementation, I bundle both data-uri-to-buffer and fetch-blob into the final result allowing us to be dependency free.
I think data-uri-to-buffer is safe to bundle because it's an internal dependency.
However, I think fetch-blob should not be bundled because it could be used by the consumer.
What do you think?
Note 1: If we do not want to bundle fetch-blob, we have to provide a CJS export for it.
Note 2: If we do not bundle fetch-blob, the install size will be very large as mentioned by @akaupi in #1217. Maybe we could make fetch-blob dependency free by using esbuild to bundle web-streams-polyfill .
https://nodejs.org/en/blog/announcements/v18-release-announce/#fetch-experimental
In Node.js 18, an experimental global fetch API is available by default.
$ node
Welcome to Node.js v18.0.0.
> fetch
[AsyncFunction: fetch]
loynoir issue egoist/tsup
Input
class Foo {}
export { Foo }
Output
var Foo = class {
};
export {
Foo
};
loynoir issue comment patriksimek/vm2
Error from '3.9.6' to '3.9.9'.
Last ok version is '3.9.5'
nodejs repl, vm2 3.9.5
> const {VM} = require('vm2');
> new VM().run('this.constructor.constructor("return process")().exit()');
> // OK
nodejs repl, vm2 3.9.9
> const {VM} = require('vm2');
> new VM().run('this.constructor.constructor("return process")().exit()');
Uncaught VMError: Unexpected access to key 'Symbol(nodejs.util.inspect.custom)'
loynoir issue patriksimek/vm2
Error from '3.9.6' to '3.9.9'.
Last ok version is '3.9.5'
loynoir issue esm-dev/esm.sh
As comparison, go install esbuild is ok
$ go install github.com/evanw/esbuild/cmd/[email protected] && echo OK
OK
$ go install github.com/esm-dev/[email protected]
go: downloading github.com/esm-dev/esm.sh v0.1.0
go: github.com/esm-dev/[email protected]: github.com/esm-dev/[email protected]: parsing go.mod:
module declares its path as: esm.sh
but was required as: github.com/esm-dev/esm.sh
$ go install [email protected]
go: [email protected]: unrecognized import path "esm.sh": parse https://esm.sh/?go-get=1: no go-import meta tags ()
Maybe change module name esm.sh to github.com/esm-dev/esm.sh?
loynoir issue comment hashicorp/vagrant
Cut networking access from a vm.
https://docs.oracle.com/en/virtualization/virtualbox/6.0/user/networkingmodes.html
Control it by
Then vagrant up fail, as it try to ssh into guest, which have been cut network access.
Vagrant 2.2.19
ArchLinux
hashicorp/bionic64
Vagrant.configure("2") do |config|
config.vm.box = "hashicorp/bionic64"
config.vm.provider "virtualbox" do |v|
# offline mode
v.customize ["modifyvm", :id, "--nic1", "none"]
# serial port
v.customize ["modifyvm", :id, "--uart1", "0x3f8", "4"]
v.customize ["modifyvm", :id, "--uartmode1", "server", "/tmp/vmserial"]
end
# config serial console inside guest
config.vm.provision "shell", inline: $config_grub_serial_console
end
$ vagrant up && minicom
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'hashicorp/bionic64'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'hashicorp/bionic64' version '1.0.282' is up to date...
==> default: Setting the name of the VM: xxx
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
default: Adapter 1: nat
==> default: Forwarding ports...
default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
default: SSH xxx
default: SSH xxx
default: SSH xxx
default: Warning: Connection refused. Retrying...
default: Warning: Connection refused. Retrying...
(~30 times)
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.
vagrant up OK.
vagrant up FAIL.
vagrant up FAILminicom OK
Some solve ideas
vagrant up fail, when guest not attach network
loynoir issue hashicorp/vagrant
Cut networking access from a vm.
https://docs.oracle.com/en/virtualization/virtualbox/6.0/user/networkingmodes.html
Control it by
Then vagrant up fail, as it try to ssh into guest, which have been cut network access.
Vagrant 2.2.19
ArchLinux
hashicorp/bionic64
Vagrant.configure("2") do |config|
config.vm.box = "hashicorp/bionic64"
config.vm.provider "virtualbox" do |v|
# offline mode
v.customize ["modifyvm", :id, "--nic1", "none"]
# serial port
v.customize ["modifyvm", :id, "--uart1", "0x3f8", "4"]
v.customize ["modifyvm", :id, "--uartmode1", "server", "/tmp/vmserial"]
end
# config serial console inside guest
config.vm.provision "shell", inline: $config_grub_serial_console
end
$ vagrant up && minicom
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'hashicorp/bionic64'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'hashicorp/bionic64' version '1.0.282' is up to date...
==> default: Setting the name of the VM: xxx
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
default: Adapter 1: nat
==> default: Forwarding ports...
default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
default: SSH xxx
default: SSH xxx
default: SSH xxx
default: Warning: Connection refused. Retrying...
default: Warning: Connection refused. Retrying...
(~30 times)
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.
vagrant up OK.
vagrant up FAIL.
vagrant up FAILminicom OK
loynoir issue hashicorp/vagrant
Is your feature request related to a problem? Please describe. Sorry, I know nothing about ruby language.
But, I guess code intelligence exists in ruby ecosystem.
And vagrantfile is written in ruby.
But I installed several vscode extensions, and see no code intelligence.
Is there code intelligence vscode solutions for ruby, or more specifically said vagrantfile?
config.vm.disk
show docs, need export VAGRANT_EXPERIMENTAL="disks"
config.vm.disk
config.vm.disk :disk, disk_ext: disk_ext, file: file, name: name, primary: primary, size: size
show nothing
show nothing
Describe the solution you'd like
Describe alternatives you've considered
Additional context Archlinux user. Install vagrant from package manager.
loynoir issue hashicorp/vagrant
Is your feature request related to a problem? Please describe.
vagrant ssh, then reboot
Expected: Able to auto reconnect
Current: Connection to xxx closed by remote host
Describe the solution you'd like
config.ssh.custom_ssh = "autossh -M 0"
Describe alternatives you've considered
Additional context
[Bug?]: repo's package.json should be updated AFTER dependency postinstall script
Self-service
Describe the bug
Actually, yarn berry update repo's package.json BEFORE dependency preinstall script.
Causing different behavior compared to both
npmandpnpmwhen running scriptTo reproduce
Reproduce
Given
repohasfoohas scriptpreinstall,install,postinstall, to detect update from which versionfoofrom1.0.22to1.0.23Actual
yarn berry output
Expected
npm output
pnpm output
Environment
Additional context
No response