The Agent's inefficiency dilemma

EDIT: Edited the Headline We ain't no Politicians to Separating Infrastructure and policy
Background
We are all aware and have discussed this issue a lot of times, with no satisfying solution.
The protocol represents a first come first serve approach when it comes to agent's filling requests. The real world data approve. All agents try to fill as fast as possible, where one (the fastest) wins and the others have the cost of a failing transaction. Currently, with a limited set of agents, we are quite balanced, but this approach as several drawbacks. Unfortunately, we need to make tradeoffs when it comes to the policy of who is able to fill the request.
tradeoffs
Let's start with the advantages of the current model. Beamer gets what we aim for. Being the fastest bridge. With the race between the agents, we incentivize being the fastest agent. And I think there is no other model which incentivizes more the speed.
Drawbacks: This speed however, comes at a high cost. This kind of "free market" approach most likely results in where neo liberal approaches end. A highly centralized set of agents. 3 to 4 agents will share the cake and rule everyone else out.
On the other hand, we could introduce some sort of fair distribution restricting the protocol, so that every agents kindly queues in and takes the request at its turn. This vastly reduces the cost, as agents wont have any failing transactions, and it would probably result in a bigger variety of agents, on the other hand we lose the incentive for filling as fast as possible.
For the agent at turn, there is no need to fill very fast, and even worse, if the agent is down, then no other agent can fill.
Of course, the third option is to build arbitrarily complex models to have a hybrid version where we find good tradeoffs. But Im convinced that these two forces, cheap cost against fast execution, are pulling at two ends of a rope, and we can definitely find compromises somewhere inbetween.
As a nice analogy I like to think about the differences of PoW and PoS. In PoW everybody starts to try finding a block, wasting lots of energy, but only the fastest wins. We most likely have constant or fast block times with this approach, but we also have lots of energy wasted for just one block.
 Every validator is kindly waiting until he is supposed to propose a block. Energy consumption is saved by 99%, but on the other side, if a validator misses its turn we wait for sure 2 block times.
Of course this is oversimplified and we are not a blockchain so we have different properties, we want to achieve. But I hope you get the analogy. In our case failing transactions is the wasted energy.
Separating Infrastructure and policy
I constantly struggled to find a decision on where the protocol should head. The current way of "free market" approach was decided on out of simplicity with the fine print we will fix it later. IOW it was an implicit decision based on simplicity. I think we are at a point where we will soon have to think about how to fix it.
And from a protocol point of view, I think we should not be the ones making the policy for all users. We should not decide whether users want to pay a higher price and get it done quickly (i.e. MEV searchers) or be happy to wait a bit but get it done cheaper.
However, I think we need to build the protocol in a way that any policy can be build on top.
Protocol Changes to facilitate any policy
I realized that we only need slight changes to the protocol in order to facilitate different policies of agents discovery.
I see the protocol as a bare metal infrastructure, which allows for a secure way for users and market makers to meet and exchange service. Policies can be built on top.
In order to allow both extremes a user needs to be able

to set an address which should be the filler of the request. All other claimers will automatically be invalid.
It may make sense to block this request for a certain amount of time, after which any other agent can be a claimer. (For this we would also need to forward the timestamp upon L1 resolution. Before only the given address is a valid claimer, afterwards anybody)

These are all changes to the protocol for now.
Use Cases
Let's have a look at potential use cases

Status quo: If the address is not set (0x0) then anybody can fill as it is today.
Proxy agent assignment: Users will send their requests to a proxy contract. In this proxy contract there is a whitelisted set of agents which will get assigned to incoming requests. Within the very transaction a request with the assigned agent gets forwarded to the RequestManager.
To me this is a business model of its own. Agents can pay some entity to be whitelisted, will have much lower cost because of they don't have failing transactions. The entity manages the list regarding reliability or liveness of the agents.
Protocol owned agents: Some protocols may want to use beamer as their underlying infrastructure protocol to facilitate bridging between chains. But they want to run their own agent to facilitate the bridging. They can assign their agent to all of their users' requests.

In all of these cases, the beamer protocol brings the security mechanism for securing users and agents. It's the protocol to ensure that no money is lost. And it still will be permissonless for challenging.
However, how the market is made and how users and agents are assigned, can be done by different entities or projects in the ecosystem.

Run the Frontend with a whitelisted set of agents: We could be the first example. For our frontend we could introduce a round robin whitelist of agents, but the protocol itself is free to use for anybody. Even further, our agents would fill any request which comes in for "the open market".
We would create a proxy contract which has a whitelisted set of agents. We could implement any kind of algorithm to fairly order the agents' turns. Users of our frontend would make their requests through our proxy.

Competition for users and agents
Different entities, setting up proxies could compete for users and agents. Agents could participate in multiple entities. And there is the open and closed market. Agents can participate in the open market at all times.
Fee implications
Now of course this is tightly coupled to the fee model. Currently we only have a protocol wide fee, which is derived from the current free market model. IOW, the minLpFee takes into account that an agent will have on average n-1 failed fill transactions until succeeding the race for a fill.
We obviously need to change the fee structure, which is an open question currently, that accounts for different policies of agent assignment. Regardless, the current fee structure was also always meant to be a short cut until we have a proper fee model. The one fee for all is not very efficient.
How to move forward
For now, this is just food for thought and my opinion how we can solve this dilemma on our plate separating it from the protocol. I would also love to design it in a way where we can iteratively incorporate such changes to the protocol. I'm sure elaborating on it together will bring a great solution.
Additional information
https://app.fireflies.ai/view/Think-tank::7pfYgjxUl4

I will try to comment on this piecewise, as I go.

We ain't no Politicians

I cannot disagree more with this. Some day I will probably write a blog about it, but for now let me just say that I view what we are doing as highly political work.
Of course we have the right to say "we do not want to decide on the policy, let others do it". However, my point is, that stance in itself is a political one, much more so in our domain than in many others. The way I see it, thinking of us as above politics is a quite fallacy. By choosing not to do something, you are very much making a political choice no matter how much you say "it is none of our business". For a nice analogy to this, consider the Ethereum community's attitude (dare I say, politics?) toward MEV.
Moreover, by explicitly pulling back from making a policy, we do not get automatically excused from considering the consequences of such a decision.

I will try to comment on this piecewise, as I go.

We ain't no Politicians

I cannot disagree more with this. Some day I will probably write a blog about it, but for now let me just say that I view what we are doing as highly political work.
Of course we have the right to say "we do not want to decide on the policy, let others do it". However, my point is, that stance in itself is a political one, much more so in our domain than in many others. The way I see it, thinking of us as above politics is quite a fallacy. By choosing not to do something, you are very much making a political choice no matter how much you say "it is none of our business". For a nice analogy to this, consider the Ethereum community's attitude (dare I say, politics?) toward MEV.
Moreover, by explicitly pulling back from making a policy, we do not get automatically excused from considering the consequences of such a decision.

Reading your comment, I clearly did not express my ideas correctly. Let me try to rephrase it.
You are completely right that we are doing political work. Thus the word politician is misplaced here.
Reading my comment further, I'm actually describing very well where we as Beamer do make policies. Namely, in the Proxy contract which is bound to the frontend, we provide.
Let me try to explain my mental model and please note, due to development shortcuts it may not be implemented this way yet:
My thinking is that, whether having a round robin style agent choice over a first come first serve principle (or even something we don't imagine yet) depends on the need of the users. And Beamer may have different types of users in the future.
The Beamer protocol is an infrastructure which provides the ability for users to exchange tokens with each other securely.
On this level, there is no real policy on how they find each other, under what conditions they exchange.
However, directly on top of this protocol (or contracts which implement the protocol), there is exactly that. Policies on how users and service providers find each other. And for sure, we are making policies. We are providers of a frontend, where I see us responsible for the proper functioning of it. This means, the frontend needs to be up, AND we need agents who are willing to provide the service to the users. We are currently making the policies how users and agents find each other and agents agree or disagree to the terms.
Nevertheless, thinking fast forward into the future, the Beamer protocol is not meant to be "the frontend" + some smart contracts in the backend. We need to split this. The beamer contracts are an infrastructure protocol for the whole world to bridge tokens securely. In my eyes, the contracts are more a technology to use instead of a specific app. The Beamer dApp is built on top. This is where all the policy should happen IMO.
And additionally, there could be multiple apps on top of the same policy.
app
--------------
policy
--------------
infrastructure

By separating it in this way, policy makers could create their own policy, which lives next to our policy. I.e. If an app wants to create a market for agents competing with each other, they can do it, if we as the Beamer team want to have a different approach for our services, we can do so. It is an open protocol to build on.

After having read the text in its entirety, I think it is an appealing idea. I expect there to be many details to sorted out, though.
One thing that comes to my mind is the question of feasibility of implementing certain fee policies in such a split approach, where we have the proxy contract and the core Beamer contracts. To give an example, suppose I want to build on top of Beamer and provide my own frontend and proxy contract. Additionally, suppose the proxy contract maintains a set of agents eligible to fill and any time there is a request, the proxy contract chooses one filler and provider that information to Beamer's request manager. Suppose now that for some reason the fill fails and now the proxy wants to penalize the agent that was chosen as the filler. How would the proxy contract get that information? Suppose I do not want to remove the agent from the agent set, but I want to apply a financial penalty. How would I go about that?

Nevertheless, thinking fast forward into the future, the Beamer protocol is not meant to be "the frontend" + some smart contracts in the backend. We need to split this. The beamer contracts are an infrastructure protocol for the whole world to bridge tokens securely. In my eyes, the contracts are more a technology to use instead of a specific app. The Beamer dApp is built on top. This is where all the policy should happen IMO.
And additionally, there could be multiple apps on top of the same policy.
app
--------------
policy
--------------
infrastructure

By separating it in this way, policy makers could create their own policy, which lives next to our policy. I.e. If an app wants to create a market for agents competing with each other, they can do it, if we as the Beamer team want to have a different approach for our services, we can do so. It is an open protocol to build on.

Yeah, I see, we're talking about Beamer both as a protocol, but also as a protocol framework, that one could use to implement other protocols (in a somewhat wider sense). In general, I find that quite nice and elegant, and from a technical level also, it definitely has some advantages.
I just wanted to make the point that each choice we make here is a political one, in certain ways. But I also agree that we can do both: turn Beamer into a protocol infrastructure and provide our own implementation on top of it, as we see fit (basically what we have now with v1, the current frontend and agents).
Thanks for expanding!

I just wanted to make the point that each choice we make here is a political one, in certain ways
totally agree. It was bad wording.

Interesting question. I think the main question is when can the outcome of a request (filled/not filled) be seen as final. From the request managers code, ultimate finality happens when a participant withdraws the token.

Right, but this is somewhat limiting because it then basically prevents ideas that could be built on top of "accumulated funds" in the contracts. I think we mentioned this a couple of times, and also there's the idea of partial/fractional fills...
I'm not sure what the best finality criteria would be, but I think we should choose it carefully in order to keep the doors open for future features.

I'm not sure whether I can follow this thought, but we should maybe postpone this discussion as it seems to be one of the details. However, a proxy can choose on its own what criteria it chooses for finality. It can also choose how agents should be penalized or even if.


A little issue about docs

Thanks for reporting this.
It's correct in the documentation on the official site but I forgot to fix it in the README somehow.
It's now fixed.


Copy annotations to KV VMI

What this PR does / why we need it:
Copy the annotations from MachineDeployment to VMI unconditionally.
Which issue(s) this PR fixes:

Fixes #
What type of PR is this?
/kind feature

Special notes for your reviewer:
Does this PR introduce a user-facing change? Then add your Release Note here:

copy annotations from MD to VMI

Documentation:

None

/approve

/lgtm


Resolve monkey-patched JS constructors better in Dartium

zones.js replaces MutationObserver with an unnamed constructor. wrap_jso uses the name to look up the wrapper, so it fails in that case. We should handle that case more robustly. I think we have some logic for that already, it just needs to be extended to non-custom elements. We should also probably take a look at how dart2js looks up interceptors and make sure we're compatible with that. Justin mentioned that Stephen had at one point talked about pulling that logic out.
@rakudrama @justinfagnani

Some of it was made available to support the web components polyfill in the past (which wrapped almost every single JS object). Maybe that is what you need here too?
Take a look at: https://github.com/dart-lang/web-components/blob/8cf45405f966d57fdade70a2e0138a20d87962f6/lib/dart_support.js
in particular how we define a transformer in window.dartNativeDispatchHooksTransformer.

Do you have something else in mind or is the dartNativeDispatchHooksTransformer sufficent? If so, maybe we can close this issue?

Clearing out 1.15 milestone as the last full push to dev has happened. If any changes are required before 1.15 is shipped, please file a merge request

Alan does the problem still exist and if so would Siggi's solution work?

According to https://github.com/angular/zone.js/issues/197 the motivating example has been rewritten. It might need the Polymer DevTools extension to be updated to that version, but the problem should go away. I think the kind of fix that Siggi mentioned would work, but if we don't have any actual problems with it it may not be that important.


[rrem] Implement basic GUI interface

When rREM is not used from command line (no parameters passed), it runs in GUI mode, allowing usage with a visual interface.
The most basic GUI interface for the tool should support:

[ ] Drag and drop of multiple files, listing them in list-rows
[ ] Add new files to list in consequent drops
[ ] Files list scrolling and file selection
[ ] Listing file type and basic file parameters
[ ] Export button to generate rres file

Follow up of issue https://github.com/raysan5/raylib/issues/193

Tool was removed from the repo and actually redesigned from scratch...


Add meta link to english version of pages

I think this looks good! Would you like to write tests for this?

Sure, though I don't have much experience in writing tests so it would be nice if you could guide me for this.

Sure, though I don't have much experience in writing tests so it would be nice if you could guide me for this.

I can think of at least two possible tests:
Test 1

Create a page with a locale other than en-latest
Render the page
Assert that the <link rel="alternate" hreflang="en" ... element exists

Test 2

Create a page with the en-latest locale
Render the page
Assert that the <link rel="alternate" hreflang="en" ... element does not exist

The existing tests in this project such as this and this should give you the basic idea on how to setup pages and do assertions.
You can use assertContains or you can make the test class extend wagtail.test.utils.WagtailTestUtils and use assertTagInHTML. Example in Wagtail.

Hi @laymonage , I have added some tests for alternate link tag. Please have a look.


Update tests

Summary of Changes:
Uncomment with no changes:

HelpCommandTest
ExitCommmandTest
ClearCommandTest
CommandResultTest
AddCommandIntegrationTest
ArgumentTokenizerTest

Uncomment with some modification:

EditCommandTest

Replace getFilteredTaskList() with getSortedTaskList()

EditTaskDescriptorTest

Add check for priority in equals()

EditTaskDescriptionBuilder

Add method withPriority

AddCommandTest

Update ModelStub with getSortedTaskList(), updateSortedTaskList(), getTagList()

AddCommandParserTest

Update tests to include Priority

EditCommandParserTest

Update tests to include Priority

ParserUtilTest

Update test to include Priority

LogicManagerTest

Refactor tests from AddressBook to Harmonia

Add tests for list tags.

Codecov Report

Merging #274 (70e52d9) into master (fcf4a92) will increase coverage by 11.28%.
The diff coverage is 50.00%.

@@              Coverage Diff              @@
##             master     #274       +/-   ##
=============================================
+ Coverage     48.14%   59.42%   +11.28%
- Complexity      383      472       +89
=============================================
  Files            89       89
  Lines          1805     1824       +19
  Branches        223      232        +9
=============================================
+ Hits            869     1084      +215
+ Misses          836      661      -175
+ Partials        100       79       -21

Impacted Files
Coverage Δ

...rc/main/java/seedu/address/model/ModelManager.java
82.53% <0.00%> (+13.18%)
:arrow_up:

src/main/java/seedu/address/model/TagList.java
84.31% <62.50%> (+37.80%)
:arrow_up:

...java/seedu/address/logic/commands/MarkCommand.java
0.00% <0.00%> (ø)

...va/seedu/address/logic/commands/UnmarkCommand.java
0.00% <0.00%> (ø)

...ava/seedu/address/logic/parser/HarmoniaParser.java
80.00% <0.00%> (+5.00%)
:arrow_up:

...n/java/seedu/address/commons/core/index/Index.java
73.33% <0.00%> (+6.66%)
:arrow_up:

...ava/seedu/address/model/task/CompletionStatus.java
81.81% <0.00%> (+9.09%)
:arrow_up:

src/main/java/seedu/address/model/TaskList.java
74.07% <0.00%> (+11.11%)
:arrow_up:

src/main/java/seedu/address/model/task/Name.java
83.33% <0.00%> (+16.66%)
:arrow_up:

... and 21 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fcf4a92...70e52d9. Read the comment docs.


Update mypy configuration

Codecov Report

Merging #15 (612cb7b) into main (32695af) will not change coverage.
The diff coverage is n/a.

Additional details and impacted files


Deploy-361 - Readme changes

The readme changes in hello-world to get the charts from charts repo rather than charts-test

Why are two of the build steps failing?

Why are two of the build steps failing?

What failures are you seeing?

I was referring to these build failures which would not seem to have anything to do with the change but I was surprised they were red:
https://bamboo.alfresco.com/bamboo/browse/PS-MKDHW2-2
https://bamboo.alfresco.com/bamboo/browse/PS-MKDHW2-3

Those failures are in Master correct?  That would be because needed structure is not there yet. The DEPLOY-310 branch is passing
On Feb 13, 2018, at 10:26 AM, Gregory Melahn <notifications<EMAIL_ADDRESS>wrote:
I was referring to these build failures which would not seem to have anything to do with the change but I was surprised they were red:
https://bamboo.alfresco.com/bamboo/browse/PS-MKDHW2-2
https://bamboo.alfresco.com/bamboo/browse/PS-MKDHW2-3
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/Alfresco/alfresco-anaxes-hello-world/pull/13#issuecomment-365340320, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAHatv-MS6urq7Fbl3kNcdIvaE2H_j2sks5tUcW2gaJpZM4R-Igy.

Those failures are in Master correct?  That would be because needed structure is not there yet. The DEPLOY-310 branch is passing

Those were on this DEPLOY-361 branch.
I believe the failures are just @svidrascu changing the Bamboo build, i.e. one task is expecting a version.properties that doesn't exist.


mattermost: 9.5.11 -> 9.11.3

Updating to next ESR for 24.11.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[x] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Let's merge #344800 first since that will get a backport and this will not.

Flagging as security related, it fixes MMSA-2024-00370.

Removing the security flag from here, the security issue has been managed in #348709

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 348398

x86_64-linux

:fast_forward: 2 packages blacklisted:

nixos-install-tools
tests.nixos-functions.nixos-test

:x: 2 packages failed to build:

mattermost
mmctl

aarch64-linux

:fast_forward: 1 package blacklisted:

nixos-install-tools

:x: 2 packages failed to build:

mattermost
mmctl

x86_64-darwin

:x: 2 packages failed to build:

mattermost
mmctl

aarch64-darwin

:x: 2 packages failed to build:

mattermost
mmctl

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 348398

x86_64-linux

:fast_forward: 2 packages blacklisted:

nixos-install-tools
tests.nixos-functions.nixos-test

:white_check_mark: 2 packages built:

mattermost
mmctl


WSL2 highly unstable in build 18922

Please fill out the below information:
Microsoft Windows [Version 10.0.18922.1000]

What you're doing and what's happening:
Running htop and VS Code in remote WSL mode.
VS Code suddenly reports Error: Error Spawn EIO and all extensions stop functioning.
From this point any Windows executables called from WSL will result in IO error, e.g. running explorer.exe returns Input/output error: explorer.exe. The only option is to run wsl.exe --shutdown from PowerShell. Problem happens again after 5 or 10 mins.
I had no issues in previous build 18917

What's wrong / what should be happening instead:
Normal operation of WSL

Strace of the failing command, if applicable:  N/A

For WSL launch issues, please collect detailed logs.

See our contributing instructions for assistance.

I think the issue is with the Golang tools or the VS Code extension, which somehow crash WSL pretty badly
Closing for now


Community Meeting, August 3, 2021

At noon Eastern, 9am Pacific, 4pm UTC; find your time
Video call link: https://meet.google.com/ohf-kwvd-mrp
Or dial: (US) +1<PHONE_NUMBER> PIN: 936<PHONE_NUMBER>#
More phone numbers: https://tel.meet/ohf-kwvd-mrp?pin=9361820877398
Or join via SIP<EMAIL_ADDRESS>This issue will collect prospective agenda topics. Add topics you'd like to discuss below!

@davidfestal working on rebasing kcp-dev/kubernetes on latest k/k 🎉
Discussions ongoing about:

physical cluster registration mechanism (OCM's model is good, see last week #137)
logical cluster -> physical cluster mapping ("objects in logical cluster A can only be scheduled to physical clusters X and Y") -- and how that works when logical clusters should be self-service
kcp storage scaling goals / limits
possible terminology updates:

"logical cluster" -> "workspace"?
"physical cluster" -> "location"? (where many "locations" might map to the same underlying physical cluster)

resource scheduling reusing node selectors vs. "location selectors"

Recording: https://youtu.be/hSQSZx7H0c4
Next: https://github.com/kcp-dev/kcp/issues/141


Implement circular progress circle.

It's not smoothed at the moment, but that can be done later (or when I figure out how to do it)

If you find any problems please let me know, but don't merge this just yet since I want to check out how colours/gradients work with this. And of course the VisualTests currently suck :P

Any reason for applying gradients via textures rather than using ColourInfo in the test case?

Textures are applied using polar coordinates, ColourInfo using Cartesian. So if you use textures you can make a circular gradient or make one end of the circular progress green and the other end red.
This actually matches the way circular gradients are implemented in Path(/sliders), and it's a way cleaner solution than my initial hack, which was adding a bool flag and changing the way triangles were coloured based on that, using the ColourInfo.
Also, Tom94 told me to do it :P


Discussion: NPM Migration Path

npm WARN deprecated<EMAIL_ADDRESS>..psst! While Bower is maintained, we recommend Yarn
and Webpack for *new* front-end projects! Yarn's advantage is security and reliability, and
Webpack's is support for both CommonJS and AMD projects. Currently there's no migration
path but we hope you'll help us figure out one.

I want to take a stab at the deprecation message's invitation to discuss a migration path.
I've tried moving a few projects from Bower to NPM, and the obvious problem that I always get stuck on is "what do I do when a package doesn't exist on npm?" Managing dependencies on both Bower and NPM at the same time isn't feasible, so I'm pretty much hosed.
So, here's a rough idea for how to allow all interested package/application authors migrate to NPM:

Each package in the Bower registry is automatically re-published to npm under the @bower/ organization scope, with source code/files untouched.
This automatic publisher generates a package.json for each Bower package based on the bower.json, correctly pointing to the other npm @bower/X dependencies.
If all Bower packages exist on NPM, application authors could then easily make their move from Bower packages to NPM's @bower/X packages without needing to change any/much source.

Because everything would be installed in the @bower/ node_modules/ subdirectory, any hardcoded ../ dependency paths would continue to work as written.
Flat installs would be supported by yarn install --flat.

Once squarely inside the npm ecosystem, applications could start moving away from @bower/X dependencies gradually.

If the "mirror Bower on NPM" part of the idea sounds crazy, there's actually already some successful precedent for this. DefinitelyTyped, for example, mirrors their big github repo of type definitions under the @types/ scope on npm. Obviously the npm team would need to be looped in to confirm/approve this for us, but it's possible.
Also worth highlighting again that this plan is focused on making the Bower->NPM migration easier. Bower's future would continue to exist outside the scope of this plan.
What does everyone think? Crazy? Feasible?

Hey! Thank you for opening this discussion.
I had similar idea as you some time ago (i.e. register all bower packages on npm), I'm even an owner of @bower organization on npm but I figured out it would be inappropriate to publish non-commonjs packages on npm's registry by non-authors in bulk.
What I decided instead is to improve yarn so it's able to install bower's packages directly from github. I've taken steps to implement it, but not 100% successfully. I hope in the near future you'll be able to yarn add dbrekalo/lang and it'll be installed in node_modules/lang.
Then there's ability of bower to install github dependencies by semver, and yarn seems to allow to accept this feature as well, if someone implements it.
Then, there's a need to write bower-migrate tool that is able to convert bower.json to package.json. It would resolve names from Bower's registry and set appropriate entries in npm's package.json, so for example "angular": "1.x" would become "angular": "angular/bower-angular#1.x".
In my opinion here are steps needed for migration:

[ ] Finish and test Allow for installing dependencies without manifest feature in Yarn (80% done)
[ ] Implement and test Branch/tag resolution for git dependencies feature in Yarn
[ ] Implement bower migrate tool that is able to convert bower.json to package.json

Of course ideally developers would gradually would use Webpack more and more and switch to CommonJS. Thanks to Yarn, most bower packages would already be installed in CommonJS form, so for example switching to CJS jQuery would be as simple as putting const $ = require('jquery') at the top of the file.

Ha! I didn't even check to see if anyone owned "@bower/", glad to hear this isn't a new idea then.
I agree that publishing non-CJS to npm is strange. It's intentionally something that can not be require'd by Node. However @types/ is a good example of a complementary ecosystem built into npm that helps npm developers, even if they can't be used as actual CJS modules (all in TS, would fail if they were ever required). Maybe the expectations of what an NPM package is have changed since you last considered it?
Those three steps sound great, really excited to see those PRs being actively worked on. I have some work I did for an auto bower.json -> package.json tool that could be useful for bower migrate, let me try to get that up somewhere for people to check out.
One concern is that those 3 steps together still don't solve the original show-stopper problem I brought up, where a Bower dependency that doesn't exist on NPM blocks the entire migration of my project. I like that if that dep doesn't have any bower.json dependencies then the git: url in your package.json would work. But if it did have bower.json dependencies then those wouldn't come through, and your install would still fail.
In my experience, that's still the biggest problem any user will have migrating to NPM/webpack/CJS/etc.

@FredKSchott Bower's package ecosystem is lacking modularity. It means that most packages don't list much dependencies except maybe frameworks like angular or jquery.
I think the solution for your problem is to write bower migrate tool, so it flattens all bower dependencies, and puts all of them into package.json. e.g. if angular-router depends on angular in bower.json, it would put both in package.json. Maybe it could also generate bower_components.js file with require statements in proper order, so you could do something like require('./bower_components') to load all legacy bower components into global.
Ultimately, most packages would maintain proper package.json, so you can start requiring it in your code (Yarn would install dependencies even of bower packages, if they have proper package.json).

So bower migrate could look at your full bower dependency tree, and generate a package.json with a github URL for each direct and indirect bower dependency listed as an npm dependency. Then the fact that it doesn't handle indirect dependencies wouldn't matter. That's really interesting...
One extra thing to think of in any solution / automatic migration: Some packages have gotten away with describing one entrypoint & set of dependencies in their bower.json for the frontend, and another entrypoint and set of dependencies in their package.json for the backend. (Ex: web-component-tester bower.json & package.json). The same git url ultimately describes two different packages (functionally).

I think the best we can do is to politely ask such authors to move development tools from dependencies to devDependencies and write proper dependencies. Until then yarn would install all their "dev" dependencies, as I'm not aware of switch that prevents it any of both npm and yarn.
And if project needs separate dependencies for front-end and back-end, I guess for now the best advice is to create separate directory for front-end (or back-end) and put 2nd package.json there.
It can be even bower_components/package.json with postinstall hook but it seems hacky.

root@iZsfb1h2cwbm97Z:~# npm install -g bower
npm WARN deprecated<EMAIL_ADDRESS>..psst! While Bower is maintained, we recommend Yarn and Webpack for new front-end projects! Yarn's advantage is security and reliability, and Webpack's is support for both CommonJS and AMD projects. Currently there's no migration path, but please help to create it: https://github.com/bower/bower/issues/2467
/usr/local/bin/bower -> /usr/local/lib/node_modules/bower/bin/bower
/usr/local/lib
└──<EMAIL_ADDRESS>

before: (bower.json)

add:
npm install script-loader
after: (vendor.ts)
/* Bower imports */ import "script-loader!../../../bower_components/jquery/dist/jquery.js"; import "script-loader!../../../bower_components/angular/angular.js"; import "script-loader!../../../bower_components/angular-animate/angular-animate.js"; import "script-loader!../../../bower_components/angular-sanitize/angular-sanitize.js"; import "script-loader!../../../bower_components/angular-resource/angular-resource.js"; import "script-loader!../../../bower_components/angular-route/angular-route.js";
or better yet..
/* Node imports */ import "script-loader!../../../node_modules/jquery/dist/jquery.js"; import "script-loader!../../../node_modules/angular/angular.js"; import "script-loader!../../../node_modules/angular-animate/angular-animate.js"; import "script-loader!../../../node_modules/angular-sanitize/angular-sanitize.js"; import "script-loader!../../../node_modules/angular-resource/angular-resource.js"; import "script-loader!../../../node_modules/angular-route/angular-route.js"; import "script-loader!../../../node_modules/angular-aria/angular-aria.js"; import "script-loader!../../../node_modules/angular-messages/angular-messages.js";

I'd like to help out on the bower migrate feature if you need help with that :)

I've already started a prototype, I'll post the link today so maybe you'd
like to take over :)
On Sat, 8 Jul 2017 at 20:35, Even Stensberg<EMAIL_ADDRESS>wrote:

I'd like to help out on the bower migrate feature if you need help with
that :)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/bower/bower/issues/2467#issuecomment-313873627, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAR2Des702v9nSFp6jzXbIAw9JuruZALks5sL8wBgaJpZM4OIRQk
.

@ev1stensberg I've pushed https://github.com/sheerun/bower2yarn with prototype, I've added you as a collaborator so you can edit directly. If anyone else would like to help, please fork and send PR (or create an issue to discuss some feature).

Awesome

this is definitely needed as it would mean and end to things like this in my projects (due to incomplete migrations to npm/yarn):
fs.symlinkSync
(
  __dirname + "/node_modules/web-animations-js",
  __dirname + "/node_modules/@polymer/web-animations-js",
  "dir"
);

@HaykoKoryun Yarn will be able to install Bower dependencies 1:1, for example in node_modules/@bower_components directory. Then you need only one symlink to migrate.

Yarn 0.28.1 includes my fixed feature to install git repositories without package.json (i.e. any Bower package). To test it you can do following:
npm install -g<EMAIL_ADDRESS>mkdir test
cd test
yarn init --yes
yarn add IndexOverflow/orange-notification#2.0.x
ls node_modules/orange-notification

What's left is this PR to support semver for git tags, finish bower2yarn migration script, and maybe write a blogposts how to a) migrate bower to yarn b) introduce webpack into legacy bower project
@chase2981 maybe you'd like to write blogpost b) ?

Would love to get involved as well, I'll jump in to the issues on bower2yarn.
Awesome work so far @sheerun + @ev1stensberg + everyone! Love to see this progressing 💯💯💯

@FredKSchott Actuallt I've not done anything yet, this is all on @sheerun :)

for powering bower in lacking modularity i use bindep tool

Figure out how to configure Webpack so it works for Global/AMD/CommonJS mixed codebase.

AMD/CommonJS/UMD is supported out of the box in webpack.
You can support modules that export via Globals with legacy-loader, imports-loader and exports-loader.

Hello Guys, I am stuck at ci-cd using jenkins. Please see the below error log.
I have jenkins pipeline in jenkinsFile . So can someone help me to resolve this issue ?
I tried to install bower using npm install -g bower in NodeJSInstallation in Global Tool Configuration setting.
`$ cmd /c "C:\Program Files (x86)\Jenkins\tools\jenkins.plugins.nodejs.tools.NodeJSInstallation\node-4.6.0\npm.cmd" install -g npm install -g bower
npm WARN deprecated<EMAIL_ADDRESS>..psst! While Bower is maintained, we recommend Yarn and Webpack for new front-end projects! Yarn's advantage is security and reliability, and Webpack's is support for both CommonJS and AMD projects. Currently there's no migration path, but please help to create it: https://github.com/bower/bower/issues/2467
C:\Program Files (x86)\Jenkins\tools\jenkins.plugins.nodejs.tools.NodeJSInstallation\node-4.6.0\bower -> C:\Program Files (x86)\Jenkins\tools\jenkins.plugins.nodejs.tools.NodeJSInstallation\node-4.6.0\node_modules\bower\bin\bower
C:\Program Files (x86)\Jenkins\tools\jenkins.plugins.nodejs.tools.NodeJSInstallation\node-4.6.0\npx -> C:\Program Files (x86)\Jenkins\tools\jenkins.plugins.nodejs.tools.NodeJSInstallation\node-4.6.0\node_modules\npm\bin\npx-cli.js
C:\Program Files (x86)\Jenkins\tools\jenkins.plugins.nodejs.tools.NodeJSInstallation\node-4.6.0\npm -> C:\Program Files (x86)\Jenkins\tools\jenkins.plugins.nodejs.tools.NodeJSInstallation\node-4.6.0\node_modules\npm\bin\npm-cli.js

<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>updated 3 packages in 136.339s
[Pipeline] stage
[Pipeline] { (check tools)
[Pipeline] sh
[C:\Program Files (x86)\Jenkins\workspace\test-project-v0.1] Running shell script
node -v
v6.10.0
[Pipeline] sh
[C:\Program Files (x86)\Jenkins\workspace\test-project-v0.1] Running shell script
npm -v
3.10.10
[Pipeline] sh
[C:\Program Files (x86)\Jenkins\workspace\test-project-v0.1] Running shell script
bower -v
C:/Program Files<EMAIL_ADDRESS>line 2: bower: command not found
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
ERROR: script returned exit code 127
Finished: FAILURE`

Also I have posted this question in google Jenkins group to see click here.

@sarjerav please make a new issue, why did you comment here?
It looks like you've not added
C:\Program Files (x86)\Jenkins\tools\jenkins.plugins.nodejs.tools.NodeJSInstallation\node-4.6.0\
To your PATH.

I am still an active user of bower but I use it for purposes of getting mostly jquery ui libraries in my projects then I use webpack to bundle them with my codebase.
My question is will there be any issue because of this need to migrate in terms of changing already written codebase ?
I honestly view bower as an awesome tool specifically for getting small ui libraries that depend on jquery mostly without having to manually download or use npm which may require to depend on any external tool like webpack or even rollup. It's more of an efficient library provider/downloader that is configurable and allows maintainability for my small projects.
My suggestion is to identify those modules that don't need to be got via bower e.g. angular, jquery and the like and let the users of bower get a notification or warning to suggest to use yarn instead.
Thanks.

I'd just like to add here that this will need to handle certain edge cases. Specifically, my team is working on moving to React 16.0. However, the bower version of React flattens the packages so that React-Dom is included in the resolution. When migrating to NPM, you will end up with react, react-dom, and prop-types as separate packages you must install. I've made a very poor, and terrible, script to handle this internally, but wanted to share it here in case it helps with this effort:
/*
 * THIS IS A DIRTY HACK
 * This *will* be removed after the migration to Yarn/NPM 3+
 */
var glob = require('glob');
var fs = require('fs-extra');
var path = require('path');
var packageJson = require('../../package.json');

/**
 * Finds and copies .js and .min.js files from specific node modules to dist/modules folder.
 * Exceptions made for react-dom since legacy architecture requires it be in the same place at React
 * @param  {[type]} dep    Name of dependency
 * @param  {[type]} folder Folder to search through using the globbing pattern we have
 * @param  {[type]} file   Glob pattern
 * @return {[type]}        Promises
 */
var findAndCopy = function(dep, folder, file) {
  return fs.ensureDir('dist/modules/' + dep)
    .then(function() {
      return new Promise(function(resolve, reject) {
        glob('node_modules/' + dep + '/' + folder + '/' + file, function(error, files) {
          if (error) reject(error);
          resolve(files);
        });
      });
    })
    .then(function(files) {
      var promises = [];

      files.forEach(function(file) {
        if (dep === 'react-dom') {
          // This needs to be in the same folder due to outdated legacy architecture
          promises.push(fs.copy(file, 'dist/modules/react/' + path.basename(file)));
          fs.remove('dist/modules/react-dom');
        } else {
          promises.push(fs.copy(file, 'dist/modules/' + dep + '/' + path.basename(file)));
        }
      });

      return Promise.all(promises);
    })
    .catch(function(error) {
      console.error('Failed to copy artifact ' + dep + ':', error);
    });
}

// Ensures existing dist modules and create folder if non existent
fs.ensureDir('dist/modules')
  .then(function() {
    var promises = [];

    // Iterate over package.json dependencies
    for (var dep in packageJson.dependencies) {
      console.log('Currently copying artifact: ' + dep);
      // Copy React (which outputs to dist directory)
      if (dep === 'react' || dep === 'react-dom') {
        promises.push(findAndCopy(dep, 'dist', '*.js'));
      }

      // Copy moment
      if (dep === 'moment') {
        promises.push(findAndCopy(dep, 'min', '*.js'));
        promises.push(findAndCopy(dep, 'locale', '*.js'));
      }

      // Copy prop-types
      if (dep === 'prop-types') {
        promises.push(findAndCopy(dep, '', 'prop-types.*'));
      }
    }

    return Promise.all(promises);
  })
  .catch(function(error) {
    console.error('Failed to copy artifacts:', error);
  });

This script is because, up until now, we have been consuming a package that resolves with bower via NPM by moving the bower resolutions to a dist folder and then publishing that as a "package" to our internal NPM repo. Once resolved, we have the projects map to that dist folder so as to "point" them to where it needs look. Obviously, this is not ideal at all and we would like to move away from this. However, I still wanted to share this with the community as it may aid in the effort to have this feature truly flushed out.

Hey @Aghassi :-)
I kinda feel like this does not necessarily need to be handled. I do understand he frustration of writing your own script to fix this but I'd suggest you open an issue with the react team if you really want to see know they differentiate between the bower and npm version of the package.
Also I think it's important to note that those are different packages. One registered with the Bower registry, containing react-dom and the other one registered with the npm registry, not containing it. So what should also ultimately work, is requiring the Bower version with yarn, giving you the same results as with Bower.

@trendy-weshy Switching Yarn with Bower won't require any changes in codebase. You could re-write your code to use require() instead of <script> and globals / AMD, but that's another task.
We're waiting for next Yarn version to be released that is able to handle both repositories without package.json and semver tags of git repositories (that's what is needed to install most of Bower packages).

@Aghassi It seems your team is switching from globals to CommonJS and that more involved task than just switching from Bower to Yarn. In particular it requires finding CommonJS-supported equivalents of all dependencies, replacking them in package.json, and changing codebase to use require().
The solution in your case is to put "react": "*" and "react-dom": "*"in package.json and something like following in your code:
const React = require('react');
const { PropTypes } = React;
const ReactDOM = require('react-dom');

@Aghassi As for the bower2yarn script, it'll list all bower dependencies flattened in package.json (even sub-dependencies), so prop-types and react-dom will be there.

@sheerun Appreciate the feedback. I will be sure to take this back to my team. We do have a few moving parts at the moment ;).
@benmann Thanks. I just wanted to throw my two cents in. If nothing else, someone stumbles across this and it helps them so they don't feel like they are the first person to come across this issue. Though, I will go open an issue against the react bower package and ask why.

@arcanis Hope you manage to release current master Yarn version as it blocks this issue :)

@sheerun We're currently on a sprint to smooth everything we can before releasing the 1.0, which is expected to come early september! 😃 In the meantime, know that we have publicly documented nightly builds that should be relatively stable (we make sure all our tests pass before merging PRs).

Yarn 1.x can install bower modules :)
Here's current blocker: https://github.com/yarnpkg/yarn/issues/4604

@sheerun looks like it's not a blocker anymore! Maybe time to deprecate bower a bit more?

@sheerun or maybe another blog post

I'm working on https://github.com/sheerun/bower2yarn script. Going to write blogpost when ready

Hello everyone! 👋
I would like to share insights on how we at Wire migrated from Bower to npm.
For our web application we use Grunt as a task runner. To make use of Bower components, we installed grunt-bower-task. The special thing about the grunt-bower-task plugin is that it reads a property called exportsOverride from the bower.json file.
The exportsOverride property makes it possible (using glob patterns) to copy Bower components into different target directories. We had to make sure that the information stored in exportsOverride is not lost when migrating from bower.json to package.json. We also had to make sure that Bower components (which are defined in a package.json file using the @bower_components prefix) are copied to their specific target directories.
To cover our requirements, we created a Grunt plugin: grunt-npm-bower.
The grunt-npm-bower plugin provides a Grunt task which copies all exportsOverride patterns from bower.json to package.json. Afterwards it copies all Bower components (found in node_modules) into their specific target directories (the ones defined in exportsOverride). If there is no exportsOverride pattern, then it will copy all contents of matched Bower components into the root of a specified folder.
Here is our entire migration workflow:

Running bower-away to migrate dependencies from bower.json to package.json (without deletion of bower.json!)
Exchanging grunt-bower-task with grunt-npm-bower
Deleting bower.json and removing grunt-bower-task

The only corner case we experienced was resolving a Zip archive. Zipped files are not supported by Yarn. Luckily Google Code Archive supported exporting projects to GitHub. This allowed us to extract the zip files and upload them to GitHub.
Our complete migration can be viewed here:

https://github.com/wireapp/wire-webapp/pull/1857

Our Grunt task is available here:

https://github.com/wireapp/grunt-npm-bower

Best,
Benny

@bennyn Thanks for sharing your approach, unfortunately our project uses gulp instead of grunt so the grunt-npm-bower  plugin won't work with gulp, it would be great if someone created the same plugin for Gulp.

@aimad-majdou Can you post your Gulp task definition which you are using to install your Bower components? Then I can have a look if it's possible to resuse the business logic from grunt-npm-bower for Gulp. 🙂

To install our bower components we use this task:
/*

BOWER
*/
gulp.task(bowerCmd, function(cb){
gutil.log(gutil.colors.yellow('Libraries installation in progress...'));
bower({ cmd: 'install'});
});

The location where the bower_components are installed, are defined in the .bowerrc:
"directory": "src/main/webapp/bower_components"
Then we use the following task to inject the bower_dependencies to the index.html :
/*
 * INJECT BOWER LIBRARIES AND APPLICATION CODE
 */
gulp.task('inject', ['minify-js'], function() {
	gutil.log(gutil.colors.yellow('JS injection in progress...'));
	return gulp.src('./src/main/webapp/index.html')
	 // inject bower libraries
  .pipe(inject(gulp.src(bowerFiles(), {read: false}),
		  {
			  name      : 'bower',
			  relative  : true,
			  // in production mode, switch to .min versions.
			  transform : function (filePath) {
				  // Exclude jquery file, we add it manualy
				  if (filePath.indexOf('jquery.js') < 0) {
					  var minFileName;
					  if (isProd()) {
						  if (isDebug()) {
							  // log current file
							  gutil.log(gutil.colors.bold.underline.magenta('Transforming file for injection: ' + filePath));
						  }
						  // MOMENT.JS case => min is in subdirectory (not standard)
						  if (filePath.indexOf('/moment.js') > 0) {
							  minFileName = filePath.replace('/moment.js', '/min/moment.min.js');
						  }
						  // NGPLUS & CALENDAR & MOMENT-DURATION-FORMAT => min is not present (not standard)
						  else if ((filePath.indexOf('/ngplus-overlay.js') > 0) || (filePath.indexOf('/calendar.js') > 0) || (filePath.indexOf('/moment-duration-format.js') > 0))  {
							  minFileName = filePath;
						  }
						  // UNDERSCORE & BACKBONE case => min is dashed (not standard)
						  else if ((filePath.indexOf('/underscore.js') > 0) || (filePath.indexOf('/backbone.js') > 0)) {
							  minFileName = filePath.replace('.js', '-min.js');
						  }
						  // DAGRE => included twice, reject this occurrence
						  else if (filePath.indexOf('/dagre.core.js') > 0) {
							  return '';
						  }
						  else if (filePath.indexOf('/dagre.core.min') > 0) {
							  minFileName = filePath;
						  }
						  // NG LETTER AVATAR => in dist folder
						  else if (filePath.indexOf('ngletteravatar') > 0) {
							  minFileName = filePath.replace('ngletteravatar.js', 'dist/ngletteravatar.min.js');
						  }
						  // NG SCROLLBARS => in dist folder
						  else if (filePath.indexOf('ng-scrollbars') > 0) {
							  minFileName = filePath.replace('src/scrollbars.js', 'dist/scrollbars.min.js');
						  }
						  // Malihu custom scrollbar plugin (NG SCROLLBARS dependecy) => specific name
						  else if (filePath.indexOf('mCustomScrollbar') > 0) {
							  minFileName = filePath.replace('jquery.mCustomScrollbar.js', 'jquery.mCustomScrollbar.concat.min.js');
						  }
						  // SNAP SVG => specific name
						  else if (filePath.indexOf('snap.svg.js') > 0) {
							  minFileName = filePath.replace('snap.svg.js', 'snap.svg-min.js');
						  }
						  else if (filePath.indexOf('snap.svg-min.js') > 0) {
							  minFileName = filePath;
						  }
						  // Charts.js => no min file
						  else if (filePath.indexOf('Chart.js') > 0) {
							  minFileName = filePath;
						  }
						  // AG GRID v5.x => no binding
						  //ag-grid/main.js
						  else if (filePath.indexOf('ag-grid-enterprise/main.js') > 0) {
							  minFileName = filePath.replace('ag-grid-enterprise/main.js', 'ag-grid-enterprise/dist/ag-grid-enterprise.min.js');
						  }
						  // angularPrint.js => no min file
						  else if (filePath.indexOf('angularPrint.js') > 0) {
							  minFileName = filePath;
						  }
						  else if (filePath.indexOf('es6-shim') >= 0) {
							  return '';
						  }
						  else {
							  if (filePath.indexOf('.min.js') === -1) {
									// ALL OTHERS => add min to the path (standard)
								  // make sure replacement is made at the end of the string
								  minFileName = filePath.substr(0, filePath.length - 3).concat('.min.js');
							  } else {
								  minFileName = filePath;
								}
						  }
						  return '<script src=\"' + minFileName + '\"></script>';
					  } else {
						  // AG GRID v5.x => no binding
						  //ag-grid/main.js
						  if (filePath.indexOf('ag-grid-enterprise/main.js') > 0) {
							  minFileName = filePath.replace('ag-grid-enterprise/main.js', 'ag-grid-enterprise/dist/ag-grid-enterprise.js');
						}
						  else if (filePath.indexOf('es6-shim') >= 0) {
							  return '';
						  }
						  else {
							  // rely on default transform for fallback
							  return inject.transform.apply(inject.transform, arguments);

						  }
						  return '<script src=\"' + minFileName + '\"></script>';
					  }
				  }
			  }
		  }))
  .pipe(// Here we only inject our application code)
  .pipe(gulp.dest('./target'));
});

Hi,
This is how I moved from using npm to yarn.
In our application we use Gulp for automating tasks in our development workflow, the first step was migrating to package.json from bower.json using bower-away, this will add the @bower_component scope to each package entry defined in the dependencies section, so after runing the Yarn installation, a sub-folder called @bower_components is created inside the node_modules folder, the only problem we had is resolving zipped files which are not supported by Yarn.
The next step was resolving zipped files issue, as a solution, I extracted and then I published them to our private npm registry with the scope @bower_components, now they can be installed by their name in our npm private registry.
When we were using bower, we defined inside .bowerrc the path to bower_components, but unfortunately this can't be done using Yarn, so I created a gulp task which copies the installed components inside node_modules/@bower_components to another target directory, something like this:
gulp.task('move-dependencies', function () {
    return gulp.src('node_modules/@bower_components/**')
               .pipe( gulp.dest(destPath + '/dependencies') );
});

The next step, is injecting the installed dependencies into our index.html page, when we were using bower, we used the main-bower-files which will read our bower.json, iterate through our dependencies and returns an array of files defined in the main property of the packages bower.json, to cover this, I created a plugin main-yarn-files forked from main-bower-files which will l read our package.json, iterate through our dependencies and returns an array of files defined in the main property of the packages package.json, some package has no package.json, so the plugin will check for bower.json, .bower.json and finally component.json, this is how this plugin is used:
var yarnFiles = require('main-yarn-files');
…
yarnFiles({
paths: {
modulesFolder: destPath + '/dependencies',
jsonFile: './package.json',
scope: '@bower'
}

})

modulesFolder : path for our dependencies (if not defined it will throw an error).
jsonFile : path for our package.json (default value: package.json).
scope : the scope used for dependencies declared in the package.json dependencies section (default value: @bower_components).

Finally, running our gulp file will :
Install dependencies using Yarn (inside node_modules/@bower_components) and devDependencies inside (node_modules),
Move dependencies inside (node_modules/@bower_components) into a target directory where the index.html page is located.
Run the main-yarn-files plugin, and inject all the returned dependencies into index.html.
Hope this will work in your case.
Cheers.

I'm investigating a current state of things with "bower -> npm" transition. Specifically I'm trying to find a way to auto-wire newly installed npm dependencies (similar to wiredep). By "auto-wire" I mean not necessarily auto-inserting script/style tags in html, but more like automatically getting all dependencies paths of installed package and then doing with them anything I want (i.e. auto-inserting import statements in js/css files, or same old auto-inserting script/style tags in html). And I don't quite understand how non-js/other dependencies can be handled in the following scenario:

we install some frontend package with npm install --save
the main field in package.json usually contains main js entry point which we can use as we want
but usually there is no notion about other files: css, other js files if present, etc.
the notion about these resources usually resides in the main field inside bower.json, i.e.: https://github.com/dimsemenov/PhotoSwipe/blob/master/bower.json
https://github.com/dimsemenov/PhotoSwipe/blob/master/package.json

The current situation is that existing packages have all info we need inside bower.json but bower is now deprecated. And at the same time there is no sufficient info inside package.json. So it's like we forced to still use bower.json to get info we need, and in the future it'll likely remain the same because I highly doubt that package authors will update packages accordingly. I understand that with webpack we can require any module we want, but still we need to manually get and insert paths for other dependencies. Could anybody share their thoughts/experience regarding this problem?

I actually prefer it the other way around: https://github.com/webpack-contrib/npm-install-webpack-plugin
Adding the import to the file cause the package to be installed

Very interesting, will definitely consider this approach. Though for arbitrary npm frontend package, there is a random set of dependency files so we can't always know ahead of time the names we need to import and even if we could — we still should manually import them. With bower and wiredep all this process was automatic... I suppose that this is sort of an edge case though, and by now we still can use bower.json if/while we can

I think this is probably a solution looking for a problem, I've been using webpack and npm for a few years now and have never needed this sort of thing

How would you handle using i.e. PhotoSwipe? You import photoswipe, webpack installs npm package automatically. Then you need to research what dependencies PhotoSwipe has (i.e. listed here https://github.com/dimsemenov/PhotoSwipe/blob/master/bower.json), and then you copy these dependencies paths and import additional js and css files manually. Is it more or less correct or I'm missing something?

I think the community favours more composable components these days
On Fri, 24 Aug 2018, 18:17 andreyvolokitin<EMAIL_ADDRESS>wrote:

How would you handle using i.e. PhotoSwipe? You import photoswipe,
webpack installs npm package automatically. Then you need to research what
dependencies PhotoSwipe has (i.e. listed here
https://github.com/dimsemenov/PhotoSwipe/blob/master/bower.json), and
then you copy these dependencies paths and import additional js and css
files manually. Is it more or less correct or I'm missing something?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/bower/bower/issues/2467#issuecomment-415824002, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAZQTOVE_D_xqV8-jeUO-ibYAZAfrw5pks5uUDUMgaJpZM4OIRQk
.

Someone suggested https://github.com/johnnyasantoss/wiredep-away on top of https://github.com/sheerun/bower-away as a way to migrate wiredep dependencies, hope it helps

I think this topic has been exhausted here, we recommend to migrate to Yarn with bower-away


Input image intensity range used in training

Hello, I don't know if this should be obvious, but I couldn't find what image intensity range was used before the mean/std normalization I see in the code. During training, were input images intensities in the uint8 0-255 range?  Or 0-1 float?

Nevermind, I just found what I believe is the training mean and variance suggesting 0-255 range:
https://github.com/facebookresearch/segment-anything/blob/3518c86b78b3bc9cf4fbe3d18e682fad1c79dc51/segment_anything/build_sam.py#L99
Thank you


Support more custom reconciliation strategy

I envision 2 main cases:

in some cases you might not want to perform a rollback even if some components are divergent. You should be able to specify this, maybe for a given entity, don't rollback for a component?
Maybe via something like: replicate.disable_rollback::<C>()

the user might not want to snap directly to the rolled-back state, but they might want to slowly interpolate towards it. In that case we might want to provide: The Previously-Predicted-State, the newly-RolledBack-State, the appropriate ticks.

let users have predicted entities but no rollback/reconciliation

This is now supported with the Correction module: https://github.com/cBournhonesque/lightyear/blob/main/lightyear/src/client/prediction/correction.rs


Theme Next: Components rounded corner support

### Tasks
- [ ] Interactive card: 4 corners rounded (currently accent bar is square) #3514
- [ ] #3523
- [ ] Pagination

Move dates to meet 7 Jul unstable provider removal date

@bhoppers2008  @dplsek to prioritise verification work for the theme release.

9th July - discussed in the attributes kick off meeting for #3536, pending solutions for:

accent bar bleeding from rounded corners issue to be addressed in card
pagination

To be closed as:

#3514 is being addressed as part of an overall card consolidation ticket - #3875
Pagination spec to be updated and tracked within #3874  instead

Corner verification work for existing components in #3536 is complete.


Roadmap?

I'm interested in working on this.
Could you tell me some ideas of what you want to do, and some tasks that you need done? Then we could work out a plan and a schedule for implementation.

Thanks for your interest!
This is a passion project for me that I plan on putting more work into after school gets a bit lighter. One of the hardest parts of learning ATS in my opinion is learning the nuances of patsopts and patscc. I am looking to create something similar to Clojure's Leiningen, the Go utility, or Rust's Cargo for ATS.
It started off as a Python script that I was working on to automate making/testing small ATS, which I just put up here, then I realized it was probably something the entire ATS community could benefit from.
I would say this this is my tentative development steps:

Develop a simple grammar for the config file. I'm currently debating the pros and cons of a JSON syntax versus a INI syntax. Would love to hear your thoughts on this. I'm leaning towards the INI-like syntax just because of it's simplicity.
Develop a parser that can turn all the configuration options into a data structure, most likely a record.
Create wrappers for all the system commands such as interacting with NPM, patsopt, and pastcc
Create a parser for the output from the above commands so I have complete control over what messages get outputted.
Add support for multiple project types (normal, atscc2js, atscc2py, etc.)
Play around with cutting NPM out of the mix and add support for directly downloading releases of plugins from GitHub (this is way down the line).

I'd love to hear your thoughts and thanks for your interest!

I look at the script -- very nice! I don't know much Python, though.
I have this issue currently: I'm tired of writing Makefiles for very, very simple programs. Here's an example of what I'm talking about (note that I'm adding more and more rules like test01_C_O). Automating it with a build tool would be nice.
I don't have any experience with Go/Rust/Clojure utilities, but I do have some with .NET Core CLI and Node NPM & WebPack.
Regarding the steps: which features do you intend to add first?
For config file syntax: I don't really mind whatever you choose. One requirement is that it should be easy to generate these files by AST manipulation (e.g. to implement something akin to npm install which adds content to the project.json file for you).
What I'm also thinking is build automation is a complex task (in general), so we should strive to automate only the most painful parts that have a good algorithmic solution (e.g. package downloading & setting up ATS search path). From what I read about Haskell Cabal, the authors say it turned out to be a very complex piece of software.

I've found this project:
http://xmake.io/
I'm thinking of creating an ATS plugin for it. While I'm at it, I think I'll add some more language plugins! Let us see how that goes.

That looks very very interesting... Why reinvent the wheel!
Haven't used lua since Middle School when I was trying my hand at modding World of Warcraft!
I still think a long-term solution is going to be a build system entirely designed for ATS, but that xmake plugin looks like it could definitely bridge the gap in the mean time!


Query : Get Identity Providers

Purpose
Added support for query GetIdentityProviders
Changes
Added support for query GetIdentityProviders
Checklist

[x] My code follows the style of this project.
[x] The code compiles without warnings.
[x] I have performed a self-review of the changes.
[x] I have documented my code, in particular the intent of the
hard-to-understand areas.
[x] (If necessary) I have updated the CHANGELOG.

CLA acceptance
By submitting the contribution I accept the terms and conditions of the
Contributor License Agreement v1.0

link: https://developers.concordium.com/CLAs/Contributor-License-Agreement-v1.0.pdf

[x] I accept the above linked CLA.

Depends On #91

Closed via https://github.com/Concordium/concordium-java-sdk/pull/131