Consider supporting patterns

Eg,
{
    "*": "src/*.js"
}

it's a convenient shorthand for when you want to export all of your internal bits.

Is this something people actually do? Ignoring lodash for a second (which surely could just write a quick script) - are there real packages that would use this pattern? This feels like it's making it easier to expose file system layout as something that looks like a stable layout. It also means that we'd need to introduce more complex precedence rules.
In short: It feels like an anti-feature to me unless I'm missing some important use case.

We have a paths feature in TS which is effectively this - people use patterns like this all the time. As much as "it feels like an antipattern" people actually do often want to expose large sets of folders and files.

Let me clarify: The proposal already does support exposing whole directories. For example the following will allow importing all files in the package:
{
  "/": "./"
}

What I'm objecting to is having the ability to make these look like true, well-defined entry points.

As much as "it feels like an antipattern" people actually do often want to expose large sets of folders and files.

The issue is this proposal aims to make it immediately visible when you are importing a file and when you are importing a reference / public API. If somebody wants to expose a directory structure, they can. But it would be exposed as a directory structure.

I'm not sure I catch the distinction? The premise is simply that you take a package local specifier that matches a pattern on the left, then map it to the path on the right, no?

The premise is that you map a fixed pattern on the left to a URL on the right. Once we start introducing patterns on the left, decisions become murky. Does * match a path segment or any number of characters? Does it transfer encoding? Can we still look at a single location or how do we sort what we try and in what order?
And all that just so that some package owners (which we haven't actually clearly identified yet, thus my assumption that we are talking about an edge case) can bulk expose an arbitrary and unchecked number of files without their consumers adding an explicit extension. And it doesn't handle cases where some of those files might be of different types (.json / binary AST / WASM).
Again: Maybe I'm missing something fundamental about the feature request but it doesn't seem to add any fundamental capability, makes the implementation and usage harder, and is - afaict - incompatible with import maps, requiring us to fork semantics. Can you give a concrete example of using this feature or of an existing project that would need it?

Again: Maybe I'm missing something fundamental about the feature request but it doesn't seem to add any fundamental capability, makes the implementation and usage harder, and is - afaict - incompatible with import maps, requiring us to fork semantics.

I'm not really sure how it would ever make usage harder, since you'll only ever be impacted by a pattern if you want to write a pattern. It does offer some interesting new abilities though, like mapping   sets of files at once without external tooling.
I very much get where you're coming from, we literally just had the same debate within the TS team about typesVersions - I myself was advocating that since most of our expected usage of it is DT, we should just do static maps (like this); however we discussed it a bunch and looked over how it would be used, in practice, and found that for the average user, a single entry with a * for mapping all the paths into the right place. I think the "mindful developer" who puposely exposes individual files as "public" would be quite a paradigm shift from where we are today.

I think the "mindful developer" who puposely exposes individual files as "public" would be quite a paradigm shift from where we are today.

I'm not sure I understand where that is coming from. All guidance I'm seeing in the ecosystem is saying "if you reach into lib or src, you're doing it wrong". IIRC babel went as far as adding protective code to all their modules to prevent people from reaching in because consumers of babel were messing with babel's ability to refactor.
I would put DT in the same camp as lodash - these are super specialized edge cases that come with all sorts of automation built around it already. This doesn't seem to be a common case for everyday module authors..?

Sufficiently large projects have private internals and files whose APIs are entirely internal, yes, but the majority of packages are smaller where every published file (or most files) in the package can safely be considered part of the API (left-pad is pretty representative). Lodash is a large library that happens to work like this, but there are a huge number of small libraries on npm that do as well. And it's not like having patterns available prevents anyone from only exposing what they want to! It's just a shorthand for exposing multiple things on one line! This isn't even an argument about a default or anything! Just a suggestion that if I do happen to have a suite of things I want exposed, I should be able to expose them easily.
And patterns do have utility! Many packages that do have an internal/external split that I've seen have, eg, an internal folder or an api folder to indicate which half is which; there's a lot of utility in being able to write a pattern that matches all of the things that could be in one of those folders when you first make it, so what you expose in the future can then be left up to convention (where it is on disk) rather than requiring tedious configuration updates later on.

Like, huge projects like babel and react are moreso the exception than the rule. I've reviewed countless single-function and handful-of-files declarations for npm packages on DT (anecdotal, I know). I'm just saying it pays to be flexible here  - you don't really lose anything by allowing people to be more expressive with the field, and glob matching is pretty common. (Tbqh it's rare to see a config file that explicitly lists every file). You'd quickly find that those questions you have have pretty reasonable default answers were you just pick up an off-the-shelf just globbing package.
Anyways, if you want an example (not mine), I was looking at amcharts related code for a bug last week, and the submitted repro had a pretty big API. Just mapping some api folder won't work here, since you need to also prevent direct access to the .internal folder.
And that's before you get into esoteric schemes where, eg, each file has an adjacent .priv.js that shouldn't be exposed or something.
I just think full pattern support would be more flexible. I really doubt supporting patterns would actively hurt much of anything.

You'd quickly find that those questions you have have pretty reasonable default answers were you just pick up an off-the-shelf just globbing package.

The implementation concerns are more about what comes after globbing (or might not be covered by *nix globs). And I'm aware of complexities there once placeholders come into play from writing asset pipeline code. Glob expansion is easy but that's not what I'm talking about when it comes to "route matching" (which this effectively is if you squint your eye).

(Tbqh it's rare to see a config file that explicitly lists every file).

The proposal doesn't suggest that. The proposal suggests either listing files or whole directories.

I've reviewed countless single-function

How would a single-function package use the glob support you describe above? If it wouldn't, why is it relevant in this context? You brought up this example repeatedly but never explained how globs would be useful there. For me the number of single-function (or single exported file) packages is a reason against the need for globs..?

handful-of-files declarations for npm packages on DT

Would it be all that bad to list a handful of public entries? I assume you'd want to document them anyhow? I certainly have packages that export a handful of files that would become simpler if I could declare them in package.json instead of having to create dummy files in the package root directory.

And that's before you get into esoteric schemes where, eg, each file has an adjacent .priv.js that shouldn't be exposed or something.

This kind of sentence is why I asked for being explicit. How would you express that kind of thing in a glob? Are we now talking about arbitrary RegExp so that it can exclude certain matches..?

Just mapping some api folder won't work here, since you need to also prevent direct access to the .internal folder.

So... how would that look in your glob solution? Is this a case where it happens to work because * won't match dot files by default? But if a package would use an internal folder, that wouldn't be supported? So somebody doing the innocent refactoring to make internal a non-hidden folder would be in for a rude awakening?
I feel like if you actually tried expressing these kinds of cases as globs (the explicit examples I asked multiple times for now), you would see where my "harder to use for consumers" is coming from. Especially if the next person needs to come in and understand what's going on.

P.S.: I also looked at amdcharts4. I don't see the harm in either mapping { "/": "./dist/es2015" } or mapping the following to exclude internal:
{
  "/core": "./dist/es2015/core.js",
  "/charts": "./dist/es2015/charts.js",
  "/maps": "./dist/es2015/maps.js",
  "/lang/": "./dist/es2015/lang/",
  "/themes/": "./dist/es2015/themes/",
}

This way the examples directory is also excluded from direct import, preventing people from depending on implementation details there. And it also works if themes would contain JSON files etc..

A few thoughts on this:

We can always add support for globs/patterns later. Nothing in the current proposal prevents that addition.
The browsers’ import maps proposal doesn’t support globs and almost certainly never will, because globs can’t be resolved without file system searching, and that’s not something that browsers can reasonably do. They don’t support automatic file extension resolution for that reason, requiring users to type .js or .mjs explicitly, because they don’t want the browser to make repeated network lookups as it hunts for a match. (This is discussed in that proposal.) One of our overriding goals is browser equivalence, of course, and so I think we should try to conform to browsers here.
It would be trivial for a tool to be written to enable globbing support. Say I wrote a tool called exports-glob-expander. It would be a CLI tool that would look for a package.json in the current folder, and look for a exports-globbed key. That key would be an object just like this repo’s proposal, but the keys and/or values would include globs. My tool would scan the folder tree of the current package and resolve all the globs, and update the package.json exports key as needed to match what it found. So in other words, users could get globbing support via a userland build tool.

So I think it’s worth leaving out, at least in the first iteration. If there’s great demand for it, so much so that a CLI tool is deemed insufficient, we can consider implementing it in a safe way.

@GeoffreyBooth
On your second point: browser equivalence is pointless for a feature like this. A browser's not going to read a package.json file for metadata, so you're going to need a tool to generate a name map from this (plus any other resolver behaviors) anyway (and I'm fairly certain that's always going to be the case unless by some happenstance a normal package.json becomes parseable as a name map - along with the nested packages jsons for your dependencies... Seems unlikely). Aiming for browser equivalence involving the name maps proposal is seems like a red herring - the name maps proposal exists to make porting projects using nodelike paths to browser resolution easier, not to make node resolution more like the browser. I don't think there's many scenarios where I'd ever want to generate a map by hand, if I'm honest - I'd almost always have something else as the ultimate source of truth for how my things resolve.
On your third point: It would be "trivial" to write a tool to hook resolution or the node environment to make this proposal unnecessary (I mean @std/esm already exists for one) that doesn't mean it's not, though - the entire point of this proposal is builtin convenience. Nobody needs to use bare imports, technically, we just really want to because we're familiar with it from cjs. The feature is entirely in the service of usability and familiarity - maximizing that usability (and ideally familiarity) seems logical.
I like to think of it this way: If you implemented this proposal as a loader, and I implemented this proposal as a loader but also supported globbing, All else the same, I'd wadger that mine would see more use. It provides value to those who want it and doesn't detract from what others would use it for. That's why I think it has value.

@weswigham If you want to propose supporting globs, I think you need to write out a detailed proposal explaining how they’d work. The current proposal treats the left-hand side as string concatenation on the package name, and that was intentional. We chose string concatenation to avoid the complexity of paths when paths aren’t really the appropriate paradigm, as import specifiers are essentially relative URLs (and are treated as such in the import maps proposal). If we allow globs on the left side, how would they work? How would that translate to another glob on the right-hand side? How would you resolve conflicts when there are multiple matches either of separate left-hand-side keys or of files matched by the right-hand-side glob?
There’s a lot of complexity to work out with supporting globs, which is why I’m inclined to leave it as a “maybe support later” improvement. If you can work out the details and all the edge cases and it all checks out, then sure, it’s worth considering.
Browser equivalence isn’t pointless for this feature. Import maps are intended to be generated from package.json files. That’s only possible if the data in package.json can be translated into the form that import maps expect. Also if import maps treat the left-hand side as URLs, and this feature is obviously so similar to it, it’s a usability concern if our version doesn’t also treat the left-hand side also like URLs.

Browser equivalence isn’t pointless for this feature. Import maps are intended to be generated from package.json files. That’s only possible if the data in package.json can be translated into the form that import maps expect. Also if import maps treat the left-hand side as URLs, and this feature is obviously so similar to it, it’s a usability concern if our version doesn’t also treat the left-hand side also like URLs.

Any static resolution scheme (including cjs as it exists today) can be mapped into package maps (partially thanks to the scoped resolution bit added to the proposal) - you just have to run the resolution and then record the final path for each possible (source, specifier) pair. Full static FS overlays like yarn's PNP file and npm's tink package map both go even father and just serialize almost the entire directory structure into a document to avoid disk hits and work very similarly in that regard. I'm pretty certain you could generate a perfectly accurate import map from one of those.
Actually looking at where the import map proposal is today, I'm certain that what node does for it's resolution in esm absolutely does not matter at all - any reasonable static resolution scheme chosen can be serialized into the map (which was a goal of the import map proposal!). Contorting node's resolution to have map-fragments built into it just to be more like the proposal seems unnecessary (and is, if I'm honest, depearting from the node ecosystem a bit). Tbqh, the remaining utility here is just having specified pkg entry points rather than implied ones; and if you want that you can probably just write a version that applies to all node resolution equally - cjs and future esm (which'd probably be neat - you can probably prototype it for cjs pretty easily with a require wrapper). And it's not really an esm concern at that point, more a node as a whole one (probably a good one at that).
You can ignore this suggestion; talking (writing?) through it has convinced me the concept as a whole doesn't have too much use in node - node can use normal cjs- like resolution for esm and it's easily adaptable to import maps in it's current form via tool; so what's the point in dumping years of community and tooling behind the current resolver?

any reasonable static resolution scheme chosen can be serialized into the map

I think we ignore what qualifies as reasonable then. :) To serialize a package using CJS rules into an offline in-memory lookup table (for efficient resolution without resource access), you need to:

List all files in the package, including resolving all symlinks (throwing if the links go outside of the package boundary because you enter 🤷♂ land).
For each file, backtrace what the possible inputs are.
Deduplicate ambiguous cases based on preference (e.g. .js beats .json).

It's possible - true. But you now have a bare specifier system that's completely out of sync with how non-bare specifiers work because for URL-based imports none of those rules would apply.

Full static FS overlays like yarn's PNP file and npm's tink package map both go even father and just serialize almost the entire directory structure into a document to avoid disk hits and work very similarly in that regard.

This proposal is aimed at making writing these "overlays" a lot simpler. Because you don't need any additional data beyond the packages & their exports (e.g. flattened into an import map) to do all resolution. The import map idea does not only apply to browsers - it's specifically interesting in node to allow:

Dynamic resource layouts that don't require multiple copies of each package in a specific directory structure, on disk, inside of the project.
Zero-stat import resolution. A packager can generate an import map by just processing package meta data and knowing where the packages are stored. From then on, the absolute URL of every import can easily be calculated in memory w/o hitting the disk.

All this is technically possible with the legacy CJS semantics. It's just much harder and leads to lots of inconsistencies. I'd rather not turn ESM into a C++ layered on top of CJS's C semantics.

All this is technically possible with the legacy CJS semantics.

I take that back. Pretty much any implementation of this I'm aware of (tink, pnp, various in-house solutions) completely overwrites the CJS module system and reimplements it. Because it's not practical on top of it, at most you can simulate (parts of) the CJS module system.

All this is technically possible with the legacy CJS semantics. It's just much harder and leads to lots of inconsistencies. I'd rather not turn ESM into a C++ layered on top of CJS's C semantics.

My argument here is simply that any nontrivial project for the foreseeable future will have cjs in the dependency tree and to produce one of those overlays you'll be simulating cjs anyway. It is unavoidable. So making it easier to generate one seems like a moot point in that regard. And since I do see cjs style resolution as beneficial and convenient, I don't see why its' support wouldn't be carried forward.


raycluster_controller: generate events for failed pod creation

Why are these changes needed?
Generate events for when the raycluster_controller fails to create:

Head pods
Worker pods

The event generated has EventTypeWarning as the event type. This commit also introduces the following event reasons as constants for ease of use and testing:

FailedToCreateResource ("Failed")
CreatedResource ("Created")
DeletedResource ("Deleted")

This commit additionally adds in tests to verify this behaviour.
Related issue number
Towards https://github.com/ray-project/kuberay/issues/2250
Checks

[x] I've made sure the tests are passing.
Testing Strategy

[x] Unit tests
[ ] Manual tests
[ ] This PR is not tested :(

cc @rueian @kevin85421

Once we can reach agreement on the right way to do this, we can also do something similar for https://github.com/ray-project/kuberay/issues/2189 and https://github.com/ray-project/kuberay/issues/2210

There is also on linter issue to fix.

@rueian I've added failure events for all failed requests made to the Kubernetes API as part of this PR itself. Can you please take an initial look?
I'll need a day or two to add in the tests as well, we can probably refactor it and add a single high level test just for events.

Also, currently, I've used the same event const for all purposes.
But for example, in the Kubelet event definition, there's distinct types defined for each category of events: https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/events/event.go
Do we want to go a similar route?

Also, currently, I've used the same event const for all purposes. But for example, in the Kubelet event definition, there's distinct types defined for each category of events: https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/events/event.go
Do we want to go a similar route?

Yes, we indeed need different event reasons for different categories. The current reason list (Failed, Created, and Deleted) is not enough.
That is because the EventCorrelator will aggregate events by fields except the Event.Message. Therefore, if we don't separate them by different Event.Reason, they will be all aggregated.

https://github.com/kubernetes/client-go/blob/master/tools/record/events_cache.go#L424-L438

@rueian thanks, that's super helpful!
Can you please take a look at the latest commit? It adds in event reason types for the following buckets:

Worker pod events
Head pod events
Generic pod events (this is a seperate bucket for events like delete events for when a cluster is suspended)
Service events
Route events
Role and RoleBinding events

Please lmk if this makess sense. Thank you!


Start job in specific time and run periodically every to 2 hours to 5 days

i want to schedule a complex job that is firing in specific time and recurring every specific time for range of another time.
example :  fire alarm sound at 12:00 am and repeating every 2 hours and ending time  of job is + 5days
when i setWindowExecution() or setExact() with setPeriodic() it's throw exception
exceptions:
Can't call setExecutionWindow() on a periodic job.
Can't require any condition for an exact job.
Here Is My Code
 JobRequest.Builder builder = new JobRequest.Builder(Constants.APP_JOB_TAG)                     .setExecutionWindow(startTime, endExecutionTime) //                    .setExact(startTime)                     .setBackoffCriteria(5_000L, JobRequest.BackoffPolicy.EXPONENTIAL)                     .setExtras(extras)                     .setRequirementsEnforced(true)                     .setUpdateCurrent(true);             if (taskModel.getTask_repeat() > 0) {                 builder.setPeriodic(taskModel.getTask_repeat() + (2 * ONE_MINUTE_IN_MILLIS), taskModel.getTask_repeat());             }             int jobId = builder.build().schedule();
do i miss understood something ? please help

Hi, @ebnrdwan !
You can't call setExecutionWindown on a periodic job.
If you want to schedule a periodic job, just set a time interval in milliseconds on setPeriodic method.
For example, I have a job that execute every 15 minutes and 5 minutes flex time interval, check it out:
JobRequest.Builder(JobServiceSync.TAG).setPeriodic(TimeUnit.MINUTES.toMillis(15), TimeUnit.MINUTES.toMillis(5)).build();

not supported yet, hope to be supported soon

Is it possible to schedule a periodic job every 2 hours but run immediately for the first time?

@pedrodimoura thanks for helping out.
feature not supported yet, hope to be supported soon

Anytime :D

Is it possible to schedule a periodic job every 2 hours but run immediately for the first time?

@mikelibg I think a Periodic Job runs at the moment you schedule for the first time and, then, after 2 hours.
But, I am not sure.


Create / Re-use existing EC2 security group

This PR changes the way security groups are used in EC2.  Previously, a security group with the name of the machine would be created on each run.  This will use a default security group of docker-machine allowing for an optional name to be specified.  If the docker-machine or specified group does not exist, machine will create it.  Machine will then confirm (and update if necessary) the port authorizations needed (currently 22 for SSH and whatever the docker port is for the driver: default 2376).
This PR also fixes a couple of race conditions in the EC2 driver found while testing: IP assigning and security group creation.
Refs: #387

LGTM


Support selection of datastore during dynamic provisioning

Currently datastore selection cannot be passed in the storage class specification and is set once during install. We need to add the ability to select a datastore.

This is tracked in PR - https://github.com/kubernetes/kubernetes/issues/40558

PR for master branch is out for review. Fix needs to be cherry picked for 1.5.x.


I'm in Azure Devops, but when I go to the boards and then create a query, I don't see the WIQL Editor tab anywhere. I'm sure I'm missing something obvious, but my question is, what am I missing? The ADO native editor sucks, and I really need the ability to write WIQL queries.
Thanks!

@ostreifel, thanks. I'd actually already checked out the More commands menu and didn't see it there, so my guess is that the person who told me that they'd installed the extension actually has not.
Thank you again, closing this "issue."

@ostreifel, thank you. I'd actually checked in the More commands menu and didn't see it listed there, so I'm guessing that the real issue is that the person who told me that they'd installed the extension didn't.
Thank you again, closing this "issue."

@ostreifel, thank you. I'd actually checked the More commands menu and didn't see it there (should have called that out in my original post). I'm guessing that the actual issue is that the person who told me that they'd installed the extension actually hasn't.
Thank you again.

@ostreifel, thanks. I'd actually already checked out the More commands menu and didn't see it there, so my guess is that the person who told me that they'd installed the extension actually has not.
Thank you again, closing this "issue."


MPMoviePlayerViewController got deprecated in iOS9. Can you please update it to have AVPlayerViewController?

XCDYouTubeVideoPlayerViewController is a subclass to MPMoviePlayerViewController and we need to use XCDYouTubeVideoPlayerViewController to play a video. It is better to have it subclass from AVPlayerViewController since MPMoviePlayerViewController deprecated in iOS 9.

Plase refer to https://github.com/0xced/XCDYouTubeKit/issues/157#issuecomment-208328872 if you absolutely want to use AVPlayerViewController.


Option to redirect from the bsky.social handle to a custom domain instead of freeing the bsky.social handle

Describe the Feature
According to the documentation: "Note: if you change your default Bluesky username (with the .bsky.social suffix) to a custom domain, your old username will be available for someone else to use."
This isn't ideal because of bad actors seeking to impersonate businesses. While some people might prefer freeing the old {USERNAME}.bsky.social ID, others who use {OFFICIAL_COMPANY_NAME}.bsky.social might prefer holding onto their original ID to avoid impersonation.
Could we add an option to preserve and redirect the original .bsky.social username when switching to a custom domain? This would let users choose whether to release or retain their original username, helping prevent impersonation while still giving flexibility to those who want to free up their old username.
Attachments
No response
Describe Alternatives
The alternative is to create a separate account after transitioning to the custom domain, for the sole purpose of reserving the ID, maybe with a profile description that points to the custom domain. But it sounds wasteful in terms of resources.
Additional Context
No response

This seems like a big issue that many people are interested in!
There are so many questions the feature leaves one asking.
Such as, what would happen to the link to this issue on Bluesky? https://bsky.app/profile/madeindex.bsky.social/post/3lacl6scs4i26
After a name change, the old name or links should simply 301 redirect to the new ones. That is also the method recommended by the World Wide Web Consortium (W3C)

I know folks who created BlueSky accounts before custom domains were available, who are reluctant to migrate to avoid their existing <handle>.bsky.social to be impersonated.
Some of them are choosing to create a dummy account which follows the custom domain to avoid impersonation. But that shows two BlueSky accounts with the same name in search results.
I feel the redirect from the bsky.social handle to a custom domain should happen automatically when someone migrates.

If this is implemented, what happens with the existing dummy accounts? I just created an account, and I don't know if it's better to wait for the redirect, or create a dummy account now with the expectation that I'll be able to merge the accounts later.

This is somewhat relevant: #5303
It seems like the team is at least aware of the issue.

It seems an important (missing) feature to me. I would propose that every account gets a .bsky.social handle, which always serves as the primary identifier and always resolves to this account, while a custom-domain handle should be an optional alias that is simply shown instead and can be used to resolve to the original handle.

That's not necessary, there already is a stable identifier (usually) of the form did:plc:….
That's surfaced sometimes when you use the share link feature on Bluesky, since that's how you make permalinks on Bluesky.
What's needed is 'just' reserving the second handle and having it continue forward to the account.
(Of course this is a quite bit more complicated in practice than me writing that down, but doesn't sound terribly difficult at least for someone already familiar with the system.)

This is a very important safety and security feature.

I'm also holding on my vanity.bluesky.social handle.
Post a skeet on your BlueSky account requesting followers who would like this feature to 👍 .
That will give data to BlueSky team to prioritize this feature request.

also just found this https://bsky.app/profile/jacob.gold/post/3kh6re46yd42k

also just found this https://bsky.app/profile/jacob.gold/post/3kh6re46yd42k
Unfortunately, this isn't a solution: Setting CNAME on the domain seems to require to actually use the same custom (sub)domain as handle already and giving up on the bsky handle.

This would be a nice feature.
For now the workaround is to create a second account with the bsky.app username but it requires a second email address. For example:

https://bsky.app/profile/joe.trusktr.io
https://bsky.app/profile/trusktr.bsky.social

Do it as soon as you switch to a new domain username, and most likely someone won't snipe your username, unless you're so popular that someone set up a bot to snipe it as soon as you release it.
Having an official option will prevent people/bots from sniping the name.

Another good reason to have this feature would be that, if people mentioned you with your old bsky.social username before you migrated to a custom domain username, we'd want those links to still go to the same user.
For example it would be great if after someone migrated from @foo.bsky.social and @foo.domain, both would link to the same profile, and any posts that mentioned my old username would not be broken.

Another good reason to have this feature would be that, if people mentioned you with your old bsky.social username before you migrated to a custom domain username, we'd want those links to still go to the same user.
For example it would be great if after someone migrated from @foo.bsky.social and @foo.domain, both would link to the same profile, and any posts that mentioned the old username would not be broken.

That already works. The mentions use DIDs internally, which don't change when the handle does.

But it would not work for links from outside that use the old handle. I think there's no way around other than keeping the bsky handle connected as failover once the user changes it to a custom domain.

I appreciate the thoughtful perspectives shared here and the valid concerns being raised. That said, I’d like to respectfully offer a different take.
Former handle reservation, especially in the federated, multi-server future envisioned for the AT Protocol, feels like quicksand, with potential for unintended long-term consequences. While the intent to prevent impersonation is understandable, allowing custom domain users to also hold an additional .bsky.social handle risks repeating the same mistakes seen on early Twitter and other centralized platforms. Without strong guardrails, Twitter’s single namespace enabled early users and parody accounts to take advantage of notable names, leaving many unavailable to their expected owners. But handles alone are inherently imperfect, and anyone can create similar or derivative alternatives, which on Twitter lead to the proliferation of @real____ and @official____ handles that, ironically, some may want to preserve when transitioning to Bluesky.
The AT Protocol’s support for custom domain handles is a clear and robust solution, and I don't think anyone in this issue disagrees. Tying identity to a domain allows users to establish unique, verifiable identities on any server without needing to reserve handles across the ecosystem, so the only real challenge is when an account moves between domains. But in the case of reserving your previous non-custom name, isn't that ultimately a temporary issue?
Mastodon has already demonstrated that tools like rel=me verification and domain-linked handles work well without requiring users to constantly chase handle reservations across new instances.
If we allow for passive handle reservations now, what about when additional AT Protocol servers pop up? By supporting some amount of official handle squatting, aren't we encouraging mass name-squatting when new AT Protocol servers emerge? What about instances that exist to squat handles en masse? The solution isn't replicating the past with long-term handle squatting, but better verification.
From a UX perspective, if you search for a notable name and get multiple results, the solution shouldn't be finding which one ends in .bsky.social, but which one offers the clearest “verification” that it is who it says it is.
For this reason, it's my opinion that more priority should be given to additional verification features and benefits that enhance trust in searches and profiles. A public record of former handles, for example, could allow labelers to clearly indicate when a handle had previously moved to a new DID or re-registered by a new account. Labelers could also flag when the same or similar handles existed across multiple domains, providing additional clarity and confidence for users. Another option could be a form of social verification, where if two accounts follow each other, they can also trade private keys offline to mark the other as a verified connection, with an ability to  display verified connections on their profiles.
I know this perspective differs from others here, but I hope it adds value to the conversation. The AT Protocol’s strength lies in its openness and scalability, and it’s critical to embrace those advantages rather than carry forward the baggage of the past.

@codybrom thanks for sharing these perspectives. I didn't think of the additional AT Protocol servers popup scenario because I'm not very familiar with the AT Protocol. Therefore obviously cannot comment - this might give me a bit of incentive to look up this aspect :) . Definietly appreciate the learn from other platform mistakes view. My vanity driven want to hold by bsky.social handle is definitely influenced by how handle registration on those social platforms have panned out. this does include domains. I want janaka.com but it's not been available for the last 25yrs. The person who has it isn't even a Janaka though to be fair isn't squatting, there's some logic to him registering it in the past. The point, Internet domain names are the grand daddy of squatting. So from my naive understanding it doesn't solve the problem anyway. So bsky would be just transferring the problem elsewhere anyway - and i don't know how far bsky should go to solve this either. Again, I'm taking the pure vanity view of this but do appreciate the instant verifiability that comes with a domain for products and organisations. But less so for individuals.

"Internet domain names are the grand daddy of squatting. So from my naive understanding it doesn't solve the problem anyway. So bsky would be just transferring the problem elsewhere anyway..."

You're so right. Domain squatters are absolutely the OGs of this, but you're bit about "transferring the problem" points to an important lesson about that fact.
Like the AT Protocol, the Domain Name System (aka DNS) is decentralized, and while domain squatting is a challenge, it hasn’t broken the Internet either. Instead, everything remains functional because it doesn’t depend on a single namespace or central authority to assign names.
Even though ICANN, the coordinating body for DNS, oversees the root namespace and ensures the system’s stability, it doesn't micromanage individual disputes or ownership claims. Instead, it delegates authority to registrars and dispute resolution providers, who handle thousands of cases each year. These arbitration systems, which are paid for by the disputing parties, resolve conflicts over intellectual property and domain ownership without ICANN itself ever stepping in. This decentralized approach allows users and organizations to establish trust and resolve disputes without a central authority controlling every decision.
Bluesky should follow the same principle. Trying to guarantee permanent ownership of extra .bsky.social handles risks turning it into even more of a default namespace than it already is, centralizing the ecosystem and making it harder for additional servers and services to ever successfully launch and grow. Instead, more focus needs to be on verification and transparency, so users can establish trusted identities without a handle availability bottleneck. That way, if a handle ever  changes hands, as long as each users is easily verifiable, it won’t really matter who has what handle. This is how a system stays decentralized, scalable, and fair while avoiding the pitfalls of centralized platforms.

yeah, agree with your point about delegated authority/management throughout in DNS is definitely better than entirely centralised. And I do like how that works with DNS, it's neat. DNS also doesn't prevent you from having multiple records pointing at the same resource. Of course the resource needs to accept each also for it to work (mostly).

This feature doesn't make handle squatting any easier. You still need to create a Bluesky account before you can move it to a custom domain.
The real concern here is impersonation. Here's why: While Bluesky's internal system keeps all the platform links working properly when someone changes domains, that doesn't help with external links from across the internet. Think about a celebrity or known organization that's been using a bsky.social handle for months - their account has probably been linked from countless blogs, news sites, Wikipedia pages, and other social networks, to name a few. Some of these links can be updated easily, but many can't.
That's where the real value lies for impersonators. It's not just about having a handle that reads famous_person.bsky.social - it's about controlling where all those external internet links lead to.
Given that handle reservation doesn't solve anything for fresh accounts, one option might be to add a minimum time requirement before allowing someone to keep their bsky.social handle when moving to a custom domain. After all, if an account has only existed for an hour, there's no real risk of external links breaking (or becoming targets for impersonators seeking that traffic). This would help prevent people from quickly creating accounts just to reserve handles before switching domains.
Does this make sense?

As I see it, there are two primary issues with being unable to retain the original username/handle:
First, as we know, after your handle is released imposters can claim it. For example, as of this writing, even though @nytimes.com is now an official handle on Bluesky, nytimes.bsky.social is again available for a squatter or imposter to grab. Same for @washingtonpost.com and washingtonpost.bsky.social.  cnn.bsky.social is taken, but is it held by CNN or someone else holding on to it to later spoof CNN?
Second, for organizations who need to maintain inbound links for previously used bsky.social handles, after renaming a handle they need to then create another separate bsky.social account to claim the previous handle. This leads to unnecessary account creations, and accounts whose only purpose will be to point visitors to the new handle. This is my own reason for being involved in this issue. I created and used the superchargeinfo.bsky.social account for 16 months before deciding to change the handle to our project name, @supercharge.info. External links to the old handle need to provide a reference to the new handle, so I had to create a second account to reclaim the old handle for the sole purpose of information visitors of our new handle. This account will count towards Bluesky statistics even though it will never be used.
The ideal solution, IMO, would be to retain the original handle but have all inbound requests for the old handle redirect to the new handle.

It looks like Bluesky is in fact quietly doing something on the backend for
"special" users - if you try to create a @nytimes.bsky.social account, you
get the error "Reserved handle".
On Mon, Nov 25, 2024 at 10:29 AM Cory Wright @.***>
wrote:

As I see it, there are two primary issues with being unable to retain the
original username/handle:
First, as we know, after your handle is released imposters can claim it.
For example, as of this writing, even though @nytimes.com is now an
official handle on Bluesky, nytimes.bsky.social is again available for a
squatter or imposter to grab. Same for @washingtonpost.com and
washingtonpost.bsky.social. cnn.bsky.social is taken, but is it held by CNN
or someone else holding on to it to later spoof CNN?
Second, for organizations who need to maintain inbound links for
previously used bsky.social handles, after renaming a handle they need to
then create another separate bsky.social account to claim the previous
handle. This leads to unnecessary account creations, and accounts whose
only purpose will be to point visitors to the new handle. This is my own
reason for being involved in this issue. I created and used the
superchargeinfo.bsky.social account for 16 months before deciding to change
the handle to our project name, @supercharge.info. External links to the
old handle need to provide a reference to the new handle, so I had to
create a second account to reclaim the old handle for the sole purpose of
information visitors of our new handle. This account will count towards
Bluesky statistics even though it will never be used.
The ideal solution, IMO, would be to retain the original handle but have
all inbound requests for the old handle redirect to the new handle.
—
Reply to this email directly, view it on GitHub
https://github.com/bluesky-social/social-app/issues/5904#issuecomment-2498333619,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABQVQHSRMB5KIG4MOMSMD7T2CM637AVCNFSM6AAAAABQM5CB22VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJYGMZTGNRRHE
.
You are receiving this because you commented.Message ID:
@.***>

It looks like Bluesky is in fact quietly doing something on the backend for "special" users - if you try to create a @nytimes.bsky.social account, you get the error "Reserved handle".

Yes, nytimes is on the list of "famous" account names that they reserved to prevent impersonation:
https://github.com/bluesky-social/atproto/blob/1e367cba2bd1ff5560c2ec5c2a5d348cd9342b65/packages/pds/src/handle/reserved.ts#L942

what is bsky's stance on all this? sorry, not sure who's giving their personal opinion vs bsky's stance.
having looked into atproto identity and DID I still don't understand arguments against aliasing. This is to solve the want to retain janaka.bsky.social and add janaka.dev, janaka.co.uk, one day janaka.com as alt handles to my account. I'm not talking about solving the famous_person.bsky.social squatting problem. I'm also not talking about any pre-account creation, the flip of squatting. assume bsky.social handles are first come first serve - all the other Janaka's that would want janaka.bsky.social, sorry. Just like on twitter, I was too late.
The handle is a friendly alias for the did:plc anyway. the field is literally called alsoKnownAs. so far i can see some UX stuff to be thought through like which alias to display as the handle, which is the primary (one solution: let the user pick and make that the first in the list). Maybe limit to the bsky.socal handle + 1 or 2 more. But I don't get the problem with supporting handle alias.
@codybrom

Trying to guarantee permanent ownership of extra .bsky.social handles risks turning it into even more of a default namespace than it already is

I think i get what you are saying here. but as you say, it is the default at the moment, that ship has sailed. again to famous person / org issue is a separate issue with some common ground.
I take you point about the complication if/when a bsky2.social comes up. I personally don't expect janaka.bsky2.social to exist out of the box. then we get into the whole Mastadon and Discord type situation. Discord has had to paper over a lot of this to improve the UX.

in the official blog post (halfway down the page) it says

Any tags or mentions with your old handle will still point to your account.

and right below there is an update now (posting here, since last comment was Nov 26)

Update as of December 12, 2024: If you change your default Bluesky username (with the .bsky.social suffix) to a website URL, your old .bsky.social username will be reserved for you. You no longer need to create a second account to reserve your most recent .bsky.social username. For every account, only your most recent .bsky.social username is reserved for you, and this reservation does not expire.

However there is no indication in the settings, if this is working as intended (and what the handle is/was).
Also since mentions get re-directed (quote above), why not have the {old_handle}.bsky.social (profile-link) do the same (if it's reserved anyways)? (which aligns pretty much with the first part of the title of this issue).

This may not quite be answering your point @n0x-space-toaster, but fwiw when you're changing your handle to a custom domain there is now text on main.bsky.dev telling you that your *.bsky.social handle will be reserved:

This will be released in 1.96 soon.

Also since mentions get re-directed (quote above), why not have the {old_handle}.bsky.social (profile-link) do the same (if it's reserved anyways)?

My understanding is that this is what should happen currently, have you seen cases where this isn't happening?

@surfdude29 i completely forgot the existence of the dev instance. But is there more to it than "just logging in there"? Because I don't see anything the like:

(or would i have had to change to custom domain while on dev for this to fully work?)

My understanding is that this is what should happen currently, have you seen cases where this isn't happening?

https://github.com/n0x-space-toaster/.space/commit/a95403a6f9a69b62ade13f5e50a5ef52fcb1bbc2#diff-0def367113e0e846336c6a70d4182e7e4821e0c4a43249f6ca96af3088064498R34
where I changed the link from https://n0xSpaceToaster.bsky.social to https://bsky.app/profile/n0x.space (ignoring the change from subdomain-style handles to sub-page style), I would except https://bsky.app/profile/n0xspacetoaster to redirect to https://bsky.app/profile/n0x.space (this also does not work on dev for me (or again, would this work if i changed handle on dev):

@n0x-space-toaster you're not seeing it because you already changed your handle away from .bsky.social, this will only work for people changing handles from now on

Would switching it back to the .bsky.social handle and then again to the custom one enable the reservation and redirect?

Because I don't see anything the like:

@n0x-space-toaster Yes what @gaearon says, and if you look at the code that text is only displayed if you're currently logged in with a .bsky.social handle:
https://github.com/bluesky-social/social-app/blob/c339dc5b05282ba917bed9d02c914453cf38d437/src/screens/Settings/components/ChangeHandleDialog.tsx#L494-L502

My understanding is that this is what should happen currently, have you seen cases where this isn't happening?

n0x-space-toaster/.space@a95403a#diff-0def367113e0e846336c6a70d4182e7e4821e0c4a43249f6ca96af3088064498R34 where I changed the link from https://n0xSpaceToaster.bsky.social to https://bsky.app/profile/n0x.space (ignoring the change from subdomain-style handles to sub-page style), I would except https://bsky.app/profile/n0xspacetoaster to redirect to https://bsky.app/profile/n0x.space (this also does not work on dev for me (or again, would this work if i changed handle on dev)

I thought redirects worked for situations like that, but it's not working for me either, so I guess not? 🤔

I tried spelunking through the codebase to figure out how the "reserved handle" change implemented, but wasn't successful.
Just for my own curiosity, how are "reserved handles" actually handled on the ATProto side of things? Does it just look through the changes through the did:plc identity changes and look for the most recent bsky.social alias and treat that as the reserved name? I tried looking through my data on PDSls but didn't find a blob for ikeviny.bsky.social, even though I confirmed my handle is reserved.

+1 that redirects aren't working after changing handle from .bsky.social to a custom domain. I had to change my handle back to my .bsky.social handle to prevent broken links to prior posts.
I will wait til Bluesky profile and post redirects work after handle updates before I move to a custom handle.

There may be a good reason from a purely tech/semantic viewpoint to not keep a .bsky.social name but from a purely brand-conscious perspective, giving one up to get the other just smells funny. Considering that Bsky themselves reserved names for major media brands in advance of them joining tells me someone over there gets this.
At this point, my finger is hovering over the custom domain button but it will remain unpressed until I get to keep both the custom name, and the original .bsky.social name - and have all links - internal and external - pointing to the .bsky.social automatically transferred to the new custom domain.
The current advice to register a custom domain and then quickly (hurry!!) re-register my old name back - even though it will break all external links, is just silly.
Sometimes the engineering/CS answer can be correct while being totally wrong.

There may be a good reason from a purely tech/semantic viewpoint to not keep a .bsky.social name but from a brand-conscious perspective, giving one up to get the other just smells funny. Considering that Bsky themselves reserved names for major media brands in advance of them joining tells me someone over there gets this.
At this point, my finger is hovering over the custom domain button but it will remain unpressed until I get to keep both the custom name, and the original .bsky.social name - and have all links - internal and external - pointing to the .bsky.social automatically transferred to the new custom domain.
The current advice to register a custom domain and then quickly (hurry!!) re-register my old name back - even though it will break all external links, is just silly.
Sometimes the engineering/CS answer can be correct while being totally wrong.

agreed - I'm not changing until it's all working either.
but some of what you are referring to isn't the latest state as per what's references here https://github.com/bluesky-social/social-app/issues/5904#issuecomment-2546741283
but it seems like the new functionality has some issues based on recent comments ^

+1 that redirects aren't working after changing handle from .bsky.social to a custom domain. I had to change my handle back to my .bsky.social handle to prevent broken links to prior posts.
I will wait til Bluesky profile and post redirects work after handle updates before I move to a custom handle.
EDIT: Unless… is there a (expected) delay before redirects are applied? I was impatient and immediately switched back to my old handle to avoid broken links.
EDIT 2: I tried again, this time allowing more time for redirects to start working. No luck so far. https://christian.bsky.social, https://bsky.app/profile/christian.bsky.social, and posts e.g. this example are all showing Unable to resolve handle or Post not found errors.

Did you first change the handle after they added the redirect functionality? Or did you originally change the handle before hand and then reverted to do it again?
Asking as I haven't changed my handle at all yet and willing to be a guinea pig to test it to rule out whether it is affecting people who changed their handles previously and have changed back, or if it is affecting new changes and old alike.

After saying I wouldn't until I could be sure,  I changed to a custom domain AFTER the new "your original handle will be reserved..." update. I can confirm that the change was fairly immediate, and the old .bsky.social mentions within Bluesky work.
However, external links: https://bsky.app/profile/[original_name}.bsky.social do NOT work. "unable to resolve handle" error
Additionally, as someone mentioned, I see no evidence that my original handle was saved. Clicking on the 'handle' settings after changing to a custom domain looks like the same dialog from creating a new account. I don't see anywhere where I can revert back to the original .bsky.social handle anywhere.

After saying I wouldn't until I could be sure, I changed to a custom domain AFTER the new "your original handle will be reserved..." update. I can confirm that the change was fairly immediate, and the old .bsky.social mentions within Bluesky work.
However, external links: [https://bsky.app/profile/original_name}.bsky.social do NOT work. "unable to resolve handle" error
Additionally, as someone mentioned, I see no evidence that my original handle was saved. Clicking on the 'handle' settings after changing to a custom domain looks like the same dialog from creating a new account. I don't see anywhere where I can revert back to the original .bsky.social handle anywhere.

I'm also considering switching to a custom domain, but it seems risky.
The old link format https://bsky.app/madeindex no longer works and redirects to the login page.
Only the link format https://bsky.app/profile/madeindex.bsky.social works.
Changing it to https://bsky.app/profile/madeindex.org could result in posts and search engine links displaying 'unable to resolve handle'? :(


flag: handles unknown arguments in an unexpected less-helpful way

If the flag library encounters an unknown parameter, it discards that parameter and dumps everything else in the positional arguments bucket.
Instead, the flag library should (optionally, probably when ContinueOnError is specified) put all unknown parameters in the positional arguments bucket (returned by Args) and keep attempting to parse the following arguments. (unless encountering something that clearly indicated the beginning of positional arguments such as the naked double-dash "--")

What version of Go are you using (go version)?
go version go1.3.3 linux/amd64
What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOBIN=""
GOCHAR="6"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/azani/go"
GORACE=""
GOROOT="/usr/lib/go"
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
CXX="g++"
CGO_ENABLED="1"
What did you do?
https://play.golang.org/p/44mXvwTfLD
What did you expect to see?

list == "first", "second", "third"
flagSet.Args() == "--something", "blah"

What did you see instead?
list == "first", "second"
flagSet.Args() == "-I", "third", "blah"
also, Parse printed an error.

The flag package can't tell whether an unknown flag takes an argument or not, so to simply continue parsing flags seems risky.

I want to make sure I understand your concern correctly:
Let's say the command line looks like this:
--unknown --known foo
The user intends for the value of unknown to be "--known" and "foo" to be a positional argument.
With the current implementation, the flagSet.Args() would return ["--known", "foo"]
With my proposed change, the flag library would put "--unknown" in the list of positional arguments and then set known equal to "foo" which is not what the user wants.
I agree this could be problematic. But it seems unlikely to come up regularly. Most likely, the program will break in a way apparent to the user and they can modify their command line to read
--unknown=--known foo
We could trigger that behavior based on an option set on the FlagSet object.
What about the other half of my proposal? It seems to me at least that flagSet.Arg() should return the first unknown argument instead of only subsequent arguments.

flag package recognizes only the following syntax for flags:
-flag
-flag=x
-flag x  // non-boolean flags only

--something doesn't match this syntax so flag package treats it as an argument.
If you change --something to -something in your example you will get  "flag provided but not defined: -something" error: https://play.golang.org/p/HopM0nOYZu

I just encountered the same issue where a user supplied a value after a boolean -verbose flag and the remaining flags were ignored.
For example: https://play.golang.org/p/GPLVZfl2XK

+1 -- I was recently writing a small go program that invoked another program with the args that were passed (amongst doing other things).  I wanted to parse 2 of the args, but leave the others unchanged.  I couldn't use the flag package

@josh-tepper I have a similar situation. What did you end up doing?

I need help, I need to accept flags that aren't defined:
https://github.com/golang/go/issues/33774
my process is started with go test, but I parse command line flags

@ORESoftware If you need help using Go, please use a forum.  Please don't post on a issue just because it happens to be related to flags.  See https://golang.org/wiki/Questions.  Thanks.


Does it need to get SVG height?

I try to remove follow lines, and it works.
// iconfont-webpack-plugin/lib/icons-to-woff.js line 52.

const iconHeight = getSvgHeight(result, filename);
if (!iconHeight) {
  return reject(new Error(`SVG font generation failed as icon "${filename}" does not have a height.`));
}

// iconfont-webpack-plugin/lib/icons-to-woff.js line 69.

/**
 * Reads the height of the svg
 *
 * @param  {String} svg      the svg content
 * @param  {String} filename the file name for error reporting
 * @return {Number}          height
 */
function getSvgHeight (svg, filename) {
  const parseSvg = /<svg[^>]+height\s*=\s*["']?(\d+)\s*(pt|px|)["']?/i.exec(svg);
  if (!parseSvg) {
    throw new Error(`could not read height for '${filename}'.`);
  }
  return parseSvg[1];
}

Without height property in svg is more useful for me. Because Illustrator outputs svgs without height property.

There used to be bugs if svgs didn’t have the same height - I don’t know if those still exists.. You should probably always provide a height otherwise the proportion of icons to each other will be wrong once they are turned into font glyphs

Thanks for your reply.
I also used to gulp-iconfont which is not required svg height.
I am pleased if height is option.

I tried to implement your plugin into our workflow. Generally speaking it works great! But the issue with the height is kind of irritating.
As a suggestion:
You could make it somewhat more robust if you parse the viewBox (set by Adobe Illustrator and Photoshop) as a fallback, or let us supply an option which can be used to set a default height. Killing webpack by throwing an error is kind of drastic (I would suggest this.emitError / this.emitWarning in your loader).
I also tried to create an svg webpack preloader, but found, that your plugin sadly does not utilize https://webpack.js.org/api/loaders#thisloadmodule to load the svg, but the fs directly, which is a bummer, as it prevents other loaders to supply the height attribute on the fly :(.
	if(!parseSvg){ 		// Check if we can read the viewbox to extract the height 		const viewbox = /<svg[^>]+viewBox\s*=\s*["']?\s?(\d{1,5}\s\d{1,5}\s\d{1,5}\s\d{1,5})\s?["']?/i.exec(source); 		let height = false; 		if(viewbox !== null && typeof viewbox[1] === "string"){ 			const viewBoxParts = viewbox[1].split(/\s+/).filter(v => v !== ""); 			if(typeof viewBoxParts[3] === "string") height = viewBoxParts[2]; 		}                 if(!height) // Fail here... 	}
Otherwise, great plugin! Thanks for sharing it.
Cheers!

@Neunerlei if it works with this.loadmodule we should definitely change it - also the error method you are suggesting is way better.
The height limitation came from the underlying library which converted svg in fonts.

@jantimon
this.loadmodule: It should work... theoretically... I did not test it for myself yet; so please don't hit mit if it doesn't 🤷♂
Just to let you know: I wrote a temporary, dirty hack which implements the solution in my last post and learned, that illustrator does stuff like this:
<?xml version="1.0" encoding="utf-8"?>
<!-- Generator: Adobe Illustrator 21.0.2, SVG Export Plug-In . SVG Version: 6.00 Build 0)  -->
<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
	 viewBox="0 0 99 99" style="enable-background:new 0 0 99 99;" xml:space="preserve">

The line break inside the svg tag killed my initial regex, so I updated my last reply to detect line breaks in svg tags as well.

@Neunerlei Your regular expression is not ready for negative values, e.g. viewBox="-243 144 13 13". Also it's not ready for multiple spaces. I recommend to use the following regular expression:
if(!parseSvg){
	// Check if we can read the viewbox to extract the height
	const viewbox = /<svg\s[^>]*viewBox\s*=\s*["']?\s*[\d.\-]+\s+[\d.\-]+\s+([\d.\-]+)\s+([\d.\-]+)\s*["']?/im.exec(source);
        const height = viewbox && viewbox[2];
        if(!height) // Fail here...
}

@jantimon Hope to see this fixed soon. I can make a PR if you agree with the viewbox solution.

@Finesse Thanks for the hint and suggestion. I updated it both in the gist and my reply.

Do we really need all that workaround? Can't we just have an option like: 'checkSvgHeight = false' and the script jumps that checking part?
I can create a PR with that option added as I'm using it locally for my projects if you guys want.

Version 4.1.0 drops the check for the svg height


docs: default Laravel namespace path

Hey TJ,
Great work on the package!
I'm building AI apps with Laravel, and I can already see how useful this will be.
This is my first pull request, which suggests an update to the README.
I recommend using the default namespace in the examples to reduce unnecessary complexity.
Thanks again for all your effort—really excited to see where this goes!

Hey! Thanks for the PR! This was a copy and paste artifact form the test suite, good catch!


Feature Request: For stopping program we can also use this

Is your feature request related to a problem? Please describe.
No response
Describe the solution you'd like.
No response
Describe alternatives you've considered
For stopping or terminating the program you can also add:
ruk ja bhai

Just a suggestion.
Additional context.
No response

What do you mean by stopping? Like exiting from the program or loop?

i think he means exit();

I think it might be like "break" in python

I think it might be like "break" in python

break is already implemented as
bas kar bhai
It's mentioned in the documentation.

exit() can be bhai chal nikal
Can't put dialogue of Hindustani Bhau.... else that would be better. :-D


feat: Add Unleash Provider

Add Unleash Provider.
See readme for details.
@sighphyre @gastonfournier @ivarconr you are welcome to review from Unleash perspective.
@Kavindu-Dodan @toddbaert you are welcome to review from OpenFeature perspective.

nice 👍🏼

I think you might have force pushed something in error, @liran2000, I'm not seeing the changed files referenced so far in the review.
I'll check back again later.

@sighphyre @Kavindu-Dodan @toddbaert thank you for the valuable feedback, I addressed your comments.

had to rebase due to missing sign-off in some commits from a different IDE.


Syncing from upstream zalando/patroni (master)

bt_gitbot

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

45 of 45 (100.0%)  changed or added relevant lines in 8 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-4.0e**-05%**) to 99.849%

Totals

Change from base Build<PHONE_NUMBER>:
-4.0e-05%

Covered Lines:
12545

Relevant Lines:
12564

💛  - Coveralls


Fix a SwiftPM 5.2 regression that cause it to try to compile unknown files in pre-5.3 manifests

SwiftPM 5.2 introduced a regression that caused a semantic change in how package manifests declaring a tools version earlier than 5.3 were parsed.  Specifically, files with an unknown source type are not ignored, as they were in SwiftPM 5.1.x and earlier.  This leads to issues such as the one reported here: https://swiftpm.slack.com/archives/C14QU6CUU/p1587442104122300

@swift-ci smoke test

@swift-ci please smoke test


Client Black Formatter: connection to server is erroring.

I am not able to make the black formatter start! I switched between different versions, I modified the values of the preferred formatters in the settings, I specified the path of the interpreter but nothing seems to work.
I am currently using Python 3.11.64, VS code tells me that Black Formatter cannot format Python files. The Black formatter output console tells me:
2023-07-31 18:07:53.849 [info] Interpreter from setting black-formatter.interpreter: C:\Users\user\AppData\Local\Programs\Python\Python311\python.exe
2023-07-31 18:07:53.849 [info] Interpreter from setting black-formatter.interpreter: C:\Users\user\AppData\Local\Programs\Python\Python311\python.exe
2023-07-31 18:07:53.849 [info] Server run command: C:\Users\user\AppData\Local\Programs\Python\Python311\python.exe c:\Users\user.vscode\extensions\ms-python.black-formatter-2023.4.1\bundled\tool\lsp_server.py
2023-07-31 18:07:53.849 [info] Server: Start requested.
2023-07-31 18:07:53.850 [info] [Error - 6:07:53 PM] Client Black Formatter: connection to server is erroring. Shutting down server.
2023-07-31 18:07:53.850 [info] [Error - 6:07:53 PM] Stopping server failed
2023-07-31 18:07:53.850 [info] Error: Client is not running and can't be stopped. It's current state is: starting
Is there anything else I can do ?

@Il-Colombo Can you try running this from a terminal and see what is happening?
C:\Users\user\AppData\Local\Programs\Python\Python311\python.exe c:\Users\user.vscode\extensions\ms-python.black-formatter-2023.4.1\bundled\tool\lsp_server.py
If there is any issue you should see an error, otherwise it will be blank and waiting. You should be able to terminate it with ctrl+c

It does not give an error and I can terminate it with ctrl+c

Can you add "black-formatter.trace.server" : "verbose" to your user settings? and also set the logging level for the extension to Trace using the "Developer: Set log level" command from the command pallet and selecting "Black Formatter" from the extension list. Click on the double tick mark icon to make the setting persistent.

Reload, and see if there is any additional information in the logs.

Nope, nothing new pops up. However  the verbose option seems to not be taken into consideration.

Do you see anything in debug console in developer tools Help > Toggle Developer Tools ?
That setting is a hidden setting, so it will look dimmed in the editor. But in the logs Output > Black Formatter, there should be few more details if the server could start up to a point where something could be extracted from the error.

Can you run chcp from a terminal and share the output? Also, can you share your environment variables?

Here is the output of the console:
2023-07-31 21:26:13.784 [info] Server run command: c:\Users\utente\AppData\Local\Programs\Python\Python311\python.exe c:\Users\utente.vscode\extensions\ms-python.black-formatter-2023.4.1\bundled\tool\lsp_server.py
2023-07-31 21:26:13.784 [info] Server: Start requested.
2023-07-31 21:26:13.784 [debug] Server State: Starting
2023-07-31 21:26:13.784 [info] [Trace - 9:26:13 PM] Sending request 'initialize - (0)'.
2023-07-31 21:26:13.784 [info] Params: {
"processId": 18440,
"clientInfo": {
"name": "Visual Studio Code",
"version": "1.80.2"
},
"locale": "en",
"rootPath": "c:\Users\utente\Git\project",
"rootUri": "file:///c%3A/Users/utente/Git/project",
"capabilities": {
"workspace": {
"applyEdit": true,
"workspaceEdit": {
"documentChanges": true,
"resourceOperations": [
"create",
"rename",
"delete"
],
"failureHandling": "textOnlyTransactional",
"normalizesLineEndings": true,
"changeAnnotationSupport": {
"groupsOnLabel": true
}
},
"configuration": true,
"didChangeWatchedFiles": {
"dynamicRegistration": true,
"relativePatternSupport": true
},
"symbol": {
"dynamicRegistration": true,
"symbolKind": {
"valueSet": [
1,
2,
3,
4,
5,
6,
7,
8,
9,
10,
11,
12,
13,
14,
15,
16,
17,
18,
19,
20,
21,
22,
23,
24,
25,
26
]
},
"tagSupport": {
"valueSet": [
1
]
},
"resolveSupport": {
"properties": [
"location.range"
]
}
},
"codeLens": {
"refreshSupport": true
},
"executeCommand": {
"dynamicRegistration": true
},
"didChangeConfiguration": {
"dynamicRegistration": true
},
"workspaceFolders": true,
"semanticTokens": {
"refreshSupport": true
},
"fileOperations": {
"dynamicRegistration": true,
"didCreate": true,
"didRename": true,
"didDelete": true,
"willCreate": true,
"willRename": true,
"willDelete": true
},
"inlineValue": {
"refreshSupport": true
},
"inlayHint": {
"refreshSupport": true
},
"diagnostics": {
"refreshSupport": true
}
},
"textDocument": {
"publishDiagnostics": {
"relatedInformation": true,
"versionSupport": false,
"tagSupport": {
"valueSet": [
1,
2
]
},
"codeDescriptionSupport": true,
"dataSupport": true
},
"synchronization": {
"dynamicRegistration": true,
"willSave": true,
"willSaveWaitUntil": true,
"didSave": true
},
"completion": {
"dynamicRegistration": true,
"contextSupport": true,
"completionItem": {
"snippetSupport": true,
"commitCharactersSupport": true,
"documentationFormat": [
"markdown",
"plaintext"
],
"deprecatedSupport": true,
"preselectSupport": true,
"tagSupport": {
"valueSet": [
1
]
},
"insertReplaceSupport": true,
"resolveSupport": {
"properties": [
"documentation",
"detail",
"additionalTextEdits"
]
},
"insertTextModeSupport": {
"valueSet": [
1,
2
]
},
"labelDetailsSupport": true
},
"insertTextMode": 2,
"completionItemKind": {
"valueSet": [
1,
2,
3,
4,
5,
6,
7,
8,
9,
10,
11,
12,
13,
14,
15,
16,
17,
18,
19,
20,
21,
22,
23,
24,
25
]
},
"completionList": {
"itemDefaults": [
"commitCharacters",
"editRange",
"insertTextFormat",
"insertTextMode"
]
}
},
"hover": {
"dynamicRegistration": true,
"contentFormat": [
"markdown",
"plaintext"
]
},
"signatureHelp": {
"dynamicRegistration": true,
"signatureInformation": {
"documentationFormat": [
"markdown",
"plaintext"
],
"parameterInformation": {
"labelOffsetSupport": true
},
"activeParameterSupport": true
},
"contextSupport": true
},
"definition": {
"dynamicRegistration": true,
"linkSupport": true
},
"references": {
"dynamicRegistration": true
},
"documentHighlight": {
"dynamicRegistration": true
},
"documentSymbol": {
"dynamicRegistration": true,
"symbolKind": {
"valueSet": [
1,
2,
3,
4,
5,
6,
7,
8,
9,
10,
11,
12,
13,
14,
15,
16,
17,
18,
19,
20,
21,
22,
23,
24,
25,
26
]
},
"hierarchicalDocumentSymbolSupport": true,
"tagSupport": {
"valueSet": [
1
]
},
"labelSupport": true
},
"codeAction": {
"dynamicRegistration": true,
"isPreferredSupport": true,
"disabledSupport": true,
"dataSupport": true,
"resolveSupport": {
"properties": [
"edit"
]
},
"codeActionLiteralSupport": {
"codeActionKind": {
"valueSet": [
"",
"quickfix",
"refactor",
"refactor.extract",
"refactor.inline",
"refactor.rewrite",
"source",
"source.organizeImports"
]
}
},
"honorsChangeAnnotations": false
},
"codeLens": {
"dynamicRegistration": true
},
"formatting": {
"dynamicRegistration": true
},
"rangeFormatting": {
"dynamicRegistration": true
},
"onTypeFormatting": {
"dynamicRegistration": true
},
"rename": {
"dynamicRegistration": true,
"prepareSupport": true,
"prepareSupportDefaultBehavior": 1,
"honorsChangeAnnotations": true
},
"documentLink": {
"dynamicRegistration": true,
"tooltipSupport": true
},
"typeDefinition": {
"dynamicRegistration": true,
"linkSupport": true
},
"implementation": {
"dynamicRegistration": true,
"linkSupport": true
},
"colorProvider": {
"dynamicRegistration": true
},
"foldingRange": {
"dynamicRegistration": true,
"rangeLimit": 5000,
"lineFoldingOnly": true,
"foldingRangeKind": {
"valueSet": [
"comment",
"imports",
"region"
]
},
"foldingRange": {
"collapsedText": false
}
},
"declaration": {
"dynamicRegistration": true,
"linkSupport": true
},
"selectionRange": {
"dynamicRegistration": true
},
"callHierarchy": {
"dynamicRegistration": true
},
"semanticTokens": {
"dynamicRegistration": true,
"tokenTypes": [
"namespace",
"type",
"class",
"enum",
"interface",
"struct",
"typeParameter",
"parameter",
"variable",
"property",
"enumMember",
"event",
"function",
"method",
"macro",
"keyword",
"modifier",
"comment",
"string",
"number",
"regexp",
"operator",
"decorator"
],
"tokenModifiers": [
"declaration",
"definition",
"readonly",
"static",
"deprecated",
"abstract",
"async",
"modification",
"documentation",
"defaultLibrary"
],
"formats": [
"relative"
],
"requests": {
"range": true,
"full": {
"delta": true
}
},
"multilineTokenSupport": false,
"overlappingTokenSupport": false,
"serverCancelSupport": true,
"augmentsSyntaxTokens": true
},
"linkedEditingRange": {
"dynamicRegistration": true
},
"typeHierarchy": {
"dynamicRegistration": true
},
"inlineValue": {
"dynamicRegistration": true
},
"inlayHint": {
"dynamicRegistration": true,
"resolveSupport": {
"properties": [
"tooltip",
"textEdits",
"label.tooltip",
"label.location",
"label.command"
]
}
},
"diagnostic": {
"dynamicRegistration": true,
"relatedDocumentSupport": false
}
},
"window": {
"showMessage": {
"messageActionItem": {
"additionalPropertiesSupport": true
}
},
"showDocument": {
"support": true
},
"workDoneProgress": true
},
"general": {
"staleRequestSupport": {
"cancel": true,
"retryOnContentModified": [
"textDocument/semanticTokens/full",
"textDocument/semanticTokens/range",
"textDocument/semanticTokens/full/delta"
]
},
"regularExpressions": {
"engine": "ECMAScript",
"version": "ES2020"
},
"markdown": {
"parser": "marked",
"version": "1.1.0"
},
"positionEncodings": [
"utf-16"
]
},
"notebookDocument": {
"synchronization": {
"dynamicRegistration": true,
"executionSummarySupport": true
}
}
},
"initializationOptions": {
"settings": [
{
"cwd": "c:\Users\utente\Git\project",
"workspace": "file:///c%3A/Users/utente/Git/project",
"args": [],
"path": [],
"interpreter": [
"c:\Users\utente\AppData\Local\Programs\Python\Python311\python.exe"
],
"importStrategy": "fromEnvironment",
"showNotifications": "onWarning"
}
],
"globalSettings": {
"cwd": "C:\Users\utente\AppData\Local\Programs\Microsoft VS Code",
"workspace": "C:\Users\utente\AppData\Local\Programs\Microsoft VS Code",
"args": [],
"path": [],
"interpreter": [],
"importStrategy": "fromEnvironment",
"showNotifications": "onWarning"
}
},
"trace": "verbose",
"workspaceFolders": [
{
"uri": "file:///c%3A/Users/utente/Git/project",
"name": "project"
}
]
}
2023-07-31 21:26:13.784 [info] [Error - 9:26:13 PM] Client Black Formatter: connection to server is erroring. Shutting down server.
2023-07-31 21:26:13.784 [info] [Error - 9:26:13 PM] Stopping server failed

@Il-Colombo Can you try "black-formatter.importStrategy": "useBundled"?

My suspicion is that it is trying to load something from the environment that is incompatible, and is causing a failure that is getting not captured correctly. I am hoping running the server with this setting "black-formatter.importStrategy": "useBundled" might get it to work right.

nope, still the same problem

This is unfortunate, I don't have enough information here to diagnose.
Can you share your environment details?

C:\Users\user\AppData\Local\Programs\Python\Python311\python.exe --version
C:\Users\user\AppData\Local\Programs\Python\Python311\python.exe -m pip list

/cc @dbaeumer Is there any way to know why this error occurs connection to server is erroring. Shutting down server.

Version 3.11.64
black              23.7.0
certifi            2023.7.22
charset-normalizer 3.2.0
click              8.1.6
colorama           0.4.6
coverage           6.5.0
coveralls          3.3.1
docopt             0.6.2
flake8             6.0.0
idna               3.4
iniconfig          2.0.0
mccabe             0.7.0
mypy-extensions    1.0.0
numpy              1.25.2
packaging          23.1
pandas             2.0.3
pathspec           0.11.2
pip                23.1.2
platformdirs       3.10.0
pluggy             1.2.0
pycodestyle        2.10.0
pyflakes           3.0.1
pytest             7.4.0
python-dateutil    2.8.2
pytz               2023.3
requests           2.31.0
setuptools         65.5.0
six                1.16.0
tzdata             2023.3
urllib3            2.0.4

@Il-Colombo Where did you install the python from? The version seems weird, the latest version from python.org is 3.11.4: https://www.python.org/downloads/release/python-3114/

sorry mine is 3.11.4 (64 bit)

Do you see anything under this?

Can you run chcp from a terminal and share the output?

Also your environment variables?

I don't see any eager

chcp -> 437
Name                           Value

__PSLockDownPolicy             0
ALLUSERSPROFILE                C:\ProgramData
APPDATA                        C:\Users\Utente\AppData\Roaming
CHROME_CRASHPAD_PIPE_NAME      \.\pipe\LOCAL\crashpad_34016_YSGJWTVEUARINKNJ
CLASSPATH                      .;C:\Program Files\Java\jdk-13.0.2\lib;C:\Program Files\Java\jdk-13.0.2\jre\lib
COLORTERM                      truecolor
CommonProgramFiles             C:\Program Files\Common Files
CommonProgramFiles(x86)        C:\Program Files (x86)\Common Files
CommonProgramW6432             C:\Program Files\Common Files
COMPUTERNAME                   NIDOMSI
ComSpec                        C:\WINDOWS\system32\cmd.exe
configsetroot                  C:\WINDOWS\ConfigSetRoot
DriverData                     C:\Windows\System32\Drivers\DriverData
GIT_ASKPASS                    c:\Users\Utente\AppData\Local\Programs\Microsoft VS Code\resources\app\extensions\git\dist\askpass.sh
HOMEDRIVE                      C:
HOMEPATH                       \Users\Utente
IntelliJ IDEA                  C:\Program Files\JetBrains\IntelliJ IDEA 2020.1.2\bin;
JAVA_HOME                      C:\Program Files\Java\jdk-13.0.2
JAVA_TOOL_OPTIONS              -Dfile.encoding="UTF-8"
JDK_HOME                       C:\Program Files\Java\jdk-13.0.2
LANG                           en_US.UTF-8
LOCALAPPDATA                   C:\Users\Utente\AppData\Local
LOGONSERVER                    \NIDOMSI
NUMBER_OF_PROCESSORS           12
OneDrive                       C:\Users\Utente\OneDrive
OneDriveConsumer               C:\Users\Utente\OneDrive
ORIGINAL_XDG_CURRENT_DESKTOP   undefined
OS                             Windows_NT
Path                           C:\Program Files (x86)\VMware\VMware Player\bin;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\Program Files\C...
PATHEXT                        .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.CPL
PROCESSOR_ARCHITECTURE         AMD64
PROCESSOR_IDENTIFIER           Intel64 Family 6 Model 158 Stepping 10, GenuineIntel
PROCESSOR_LEVEL                6
PROCESSOR_REVISION             9e0a
ProgramData                    C:\ProgramData
ProgramFiles                   C:\Program Files
ProgramFiles(x86)              C:\Program Files (x86)
ProgramW6432                   C:\Program Files
PSModulePath                   C:\Program Files (x86)\Wiechecki.it\PowerShell\Modules;C:\Program Files\WindowsPowerShell\Modules;C:\WINDOWS\system32\Windo...
PUBLIC                         C:\Users\Public
PyCharm                        C:\Program Files\JetBrains\PyCharm 2020.1.2\bin;
SESSIONNAME                    Console
SystemDrive                    C:
SystemRoot                     C:\WINDOWS
TEMP                           C:\Users\Utente\AppData\Local\Temp
TERM_PROGRAM                   vscode
TERM_PROGRAM_VERSION           1.80.2
TMP                            C:\Users\Utente\AppData\Local\Temp
USERDOMAIN                     NIDOMSI
USERDOMAIN_ROAMINGPROFILE      NIDOMSI
USERNAME                       Utente
USERPROFILE                    C:\Users\Utente
VBOX_MSI_INSTALL_PATH          C:\Program Files\Oracle\VirtualBox
VSCODE_GIT_ASKPASS_EXTRA_ARGS  --ms-enable-electron-run-as-node
VSCODE_GIT_ASKPASS_MAIN        c:\Users\Utente\AppData\Local\Programs\Microsoft VS Code\resources\app\extensions\git\dist\askpass-main.js
VSCODE_GIT_ASKPASS_NODE        C:\Users\Utente\AppData\Local\Programs\Microsoft VS Code\Code.exe
VSCODE_GIT_IPC_HANDLE          \.\pipe\vscode-git-cf0da6c614-sock
VSCODE_INJECTION               1
windir                         C:\WINDOWS
ZES_ENABLE_SYSMAN              1

Do you see anything under this?

@Il-Colombo I needed the output from Extension Host. From Output > Extension Host.

@dbaeumer I have a seen a few reports of this type of issue. In some cases, for whatever reason, spawning the process manually and handing the stdio streams to LSP client works better than having LSP client launch it. Looking at the LSP client code I don't see what is going wrong, it seems to launch it normally as one would using node spawn. Is there any way we can extract details on why the stream is erroring? Like did the process exit, if so what was the exit code, or something was written to the stream that it should not have, etc.

@karthiknadig this most of the time happens if the process can be started and then an exception occurs in the server process before it reached the code reading messages (in node for example a require statement fails).
I currently don't print this to the LOG but I should. I opened https://github.com/microsoft/language-server-protocol/issues/1784
Feel free to provide a PR. Code will go into https://github.com/microsoft/vscode-languageserver-node/blob/f2ff7d55464a1f58f978cb6635bd8865f050553c/client/src/node/main.ts#L1

I am still experiencing this issue & am receiving error code 32097 .. is there currently a known solution?

@lyndseyjw A solution you can try is to point the black-formatter.interpreter to run using python that is not the one in your environment. This error occurs when some package in the environment loads on python load and writes to stdout. We are working on solution for this that avoids working over stdout.
Here is what I recommend you try:
Set black-formatter.importStrategy as useBundled. Set black-formatter.interpreter to python from your system. On windows you can set it to a python.exe or ["py", "-3"]. On mac/linux you can set it to /usr/bin/python3. See if this works, if not we'll need to dig further on what is causing a write to stdout.

hi @karthiknadig ! Adding both "black-formatter.importStrategy": "useBundled" & "black-formatter.interpreter": ["/usr/bin/python3"] to my settings.json file worked for me, thank you so much!

I have tried everything in this thread and nothing seems to work. This has really disrupted my workflow.

@dcgudeman You can pin the ms-python.python extension to 2023.18.0 or older to use the old mechanism old formatting. You can do that by selecting "Install another version" option from the extensions view.
As for using this extension, If you have tried the suggestion here https://github.com/microsoft/vscode-black-formatter/issues/280#issuecomment-1799803439 then you need to check if any of the packages installed in the interpreter chosen to run the black server are writing to stdout. Avoid installing packages into the system python, as it can break normal operation of not only some of your projects but can break some system processes as well.

@dcgudeman The issue stems from how VSCode and python communicate. We are working on an alternate mode of communication that does not rely on stdout. Some packages do the wrong thing of writing to stdout on load, this is not common. Typically, nothing should write to stdout on import.
You can apply the same fix to isort extension as well. isort.interpreter and isort.importStrategy should address this.
There is another alternative. You can use Ruff extension, apply this fix to it once, and ruff can do import sorting similar to isort, formatting similar to black, and it implements multiple linters (pylint, flake8, pycodestyle, pydocstyle, etc). It is written in rust so it is incredibly fast.

@karthiknadig what is the status of this issue? Has a version been released with a fix?

A possible reason is that, you choose an environment that is not compatible with black formatter, such as pydoc3.10 or so


Increase the test timeout as we add more tests

LGTM

I understand we need to increase the timeout, because travis is sometime overloaded, but
I'm not agreed with the 5 minute timeout, as :
o We consume (unit second) 40 user 2 system 50 real
o In case of Fail the CI is locked for 5min
So let's setup a relative conservative value to 90 sec or 2 min.
This will be more productive for all of us.

We experienced working tests over the 5 minutes. Restarting any CI job will consume more than that (I'm really writing this :).