TypeScript types

The TypeScript declaration package is missing in https://www.npmjs.com/~types .
More information on this: https://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html
This is very important to ensure a proper diffusion of the cloudevents standards.

@micheleangioni Could you make a PR with this? If you can't, please write an example using some piece of code from sdk.

I do not have the complete library definitions. I have the definitions of the Spec01, Spec02 and Cloudevent classes.
This are the definitions are wrote:
declare module 'cloudevents-sdk' {
  export type SpecPayload = {
    [key: string]: any,
  };

  export class Spec01 {
    public payload: SpecPayload & {
      cloudEventsVersion: '0.1',
      eventID: string,
    };

    public check(): void;

    public type(type: string): Spec01;
    public getType(): string|undefined;

    public getSpecversion(): string;

    public eventTypeVersion(eventTypeVersion: string): Spec01;
    public getEventTypeVersion(): string|undefined;

    public source(source: string): Spec01;
    public getSource(): string|undefined;

    public id(id: string): Spec01;
    public getId(): string|undefined;

    public schemaurl(schemaurl: string): Spec01;
    public getSchemaurl(): string|undefined;

    public contenttype(contenttype: string): Spec01;
    public getContenttype(): string|undefined;

    public data(data: any): Spec01;
    public getData(): any;

    public time(time: Date): Spec01;
    public getTime(): string|undefined;

    public addExtension(key: string, value: any): Spec01;
  }

  export class Spec02 {
    public payload: SpecPayload & {
      specversion: '0.2',
      id: string,
    };

    public check(): void;

    public type(type: string): Spec02;
    public getType(): string|undefined;

    public getSpecversion(): string;

    public eventTypeVersion(eventTypeVersion: string): Spec02;
    public getEventTypeVersion(): string|undefined;

    public source(source: string): Spec02;
    // public getSource(): string|undefined; // TODO Missing getter, to be added. See https://github.com/cloudevents/sdk-javascript/pull/8

    public id(id: string): Spec02;
    public getId(): string|undefined;

    public time(time: Date): Spec02;
    public getTime(): string|undefined;

    public schemaurl(schemaurl: string): Spec02;
    public getSchemaurl(): string|undefined;

    public contenttype(contenttype: string): Spec02;
    public getContenttype(): string|undefined;

    public data(data: any): Spec02;
    public getData(): any;

    public addExtension(key: string, value: any): Spec02;
  }

  export type Extensions = {
    [key: string]: any,
  };

  export class JSONFormatter01 {
    public format(payload: SpecPayload): SpecPayload;
    public toString(payload: SpecPayload): string;
  }

  export default class Cloudevent {
    public static specs: {
      0.1: Spec01,
      0.2: Spec02,
    };

    public static formats: {
      'json': JSONFormatter01,
      'json0.1': JSONFormatter01,
    };

    public static bindings: {
      'http-structured': any,
      'http-structured0.1': any,
      'http-structured0.2': any,
      'http-binary0.1': any,
      'http-binary0.2': any,
    };

    public constructor(spec?: Spec01|Spec02, formatter?: JSONFormatter01);

    public format(): SpecPayload;
    public toString(): string;

    public type(type: string): Cloudevent;
    public getType(): string|undefined;

    public getSpecversion(): string;

    public source(type: string): Cloudevent;
    public getSource(): string|undefined;

    public id(id: string|number): Cloudevent;
    public getId(): string|undefined;

    public time(type: Date): Cloudevent;
    public getTime(): string|undefined;

    public schemaurl(schemaurl: string): Cloudevent;
    public getSchemaurl(): string|undefined;

    public contenttype(contenttype: string): Cloudevent;
    public getContenttype(): string|undefined;

    public data(data: any): Cloudevent;
    public getData(): any;

    public addExtension(key: string, value: any): Cloudevent;
    public getExtensions(): Extensions;
  }
}

@micheleangioni Now I understood. Do you want to join us and work in this issue?

Yes, sure. I hope to find some time to write the declarations also of the remaining classes, hopefully in a couple of weeks :)

@micheleangioni, would be awesome!
Novice question, how to use the type definition above w/ cloudevents-sdk?  I placed the type definition here<EMAIL_ADDRESS>but it's unclear how to create a Cloudevent with a JSON string.
Thanks.

@micheleangioni, I had to change the typing to the following to match cloudevents.js's single export of Cloudevent.
https://gist.github.com/cwallsfdc/183c2df8dad88964efa957217b12c496

@cwallsfdc Can you help us in how to publish this typing in NPM?

Honestly, I think a better approach is to convert to Typescript and include the typings in the cloudevents-sdk npm module.  This way the lib and typing stay aligned.  Migrating to Typescript shouldn't disrupt users.
If in agreement, I can post a PR w/ Typescript changes.  We'd then publish a new cloudevents-sdk version w/ typings.
Thoughts?

LGTM

Google Cloud Functions uses it's own TypeScript types because this SDK does not have them.
Google Cloud Functions Framework:
https://github.com/GoogleCloudPlatform/functions-framework-nodejs/blob/master/src/invoker.ts#L63

Answering questions from email:

When the sdk converted to ts, we can use it in pure js projects?

Yes. When we publish to npm, we publish pure js and we have files for TypeScript types for autocompletion.

I am comfortable with this approach, using definitely typed.

We can publish this npm module instead of using DefinitelyTyped. See https://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html

Just let me know when master and dev are the same so I can do the conversion without new changes in the middle. It will take a bit of time.

@grant Thanks for the answers.
Because of the changes that are coming from the spec, I think that is more prudence to publish the types using Definitely Typed. This will help the projects written in TypeScript and we save time to model the stuff for the future of the sdk and to work in the incoming spec changes.
It's fair if we make voting:

Vote a if you are in favor of to create just the types and publish to  DefinitelyTyped
Vote b if you are in favor of to migrate the entire codebase from JavaScript to TypeScript

What do you thing about that @grant ?
rigth now, master and develop remains the same

b is so much better and easier.
This is what Google does with all JavaScript libraries.

@micheleangioni
@cwallsfdc

Thanks for leading this charge @fabiojose.
I agree with @grant.  b.  TypeScript is natural and well supported.

b wins!
Vote b if you are in favor of to migrate the entire codebase from JavaScript to TypeScript
@grant Thanks for your contribution! Let's code?

@grant
Will you code for this issue? Just to know.

I can't continue since this repo doesn't seem to follow the CNCF standards of having reviews. Need to check on Slack and with others first.

Nice!
This is a great opportunity. You can become a new commiter and helps us to review. At this moment I am the only one: maintainer and commiter.
Because of that, I guess, you got that impression of loose standards.
Come, join us! Make this better!

this repo doesn't seem to follow the CNCF standards of having reviews

@grant can you elaborate?  As @fabiojose mentioned, we do try to follow "normal" review processes (see the golang repo, it has more people involved) but if there's only one person active in the repo then it's hard to require multiple people for reviews :-)

I would like to join migrating cloudevents to typescript!

Now we are using PRs, but I must approve by myself. You can help us in the review of that PRs.
Is that makes senses to you?

Makes sense. I can look into converting this package again. It needs a lot of major changes though.

Folks, it's not the best, but now we have (types for version 1.0.0)[https://github.com/cloudevents/sdk-javascript/blob/v1/v1/index.d.ts]

A remark from a (rather inexperienced) typescript user: the provided types are not really flexible as they are more of an interface than a type definition. I think the whole structure would be much more versatile (i.e. usable in / connectable to other libraries) if you split the event builder pattern from the bare data model and use basic object attributes instead of getters and setters in the type definition.
In my case, I wanted to receive the events from rabbitmq and store them in mongodb but both libraries expect type definitions with bare objects (and for instance iterate over their keys).

Nice!
This is a great opportunity. You can become a new commiter and helps us to review. At this moment I am the only one: maintainer and commiter.
Because of that, I guess, you got that impression of loose standards.
Come, join us! Make this better!

Hi @fabiojose,
Do you mind making me a collaborator to this repo? I have an expertise in JavaScript/TypeScript and would really like to make this project better.
At Google, we don't use this CloudEvent SDK (even though we use CloudEvents with Node) because of some of the issues described above. I would like to improve this situation but I need to be able to contribute to this repo and use best practices.
To restart trying with this repo, I've created a simple PR:
https://github.com/cloudevents/sdk-javascript/pull/63
After that, I would love to help with doing things like simplifying the multiple versions we have in this repo and conversion to modern TypeScript.

For me, it's ok.
Please, file an issue requesting to be a collaborator and I will ask someone to add you.

For me, it's ok.
Please, file an issue requesting to be a collaborator and I will ask someone to add you.

Ok, I filed an issue:
https://github.com/cloudevents/sdk-javascript/issues/64

@grant @fabiojose I would like to request that this repository NOT be converted to TypeScript. It is a mistake, in my opinion to assume that JavaScript and TypeScript are interchangeable.

@grant @fabiojose I would like to request that this repository NOT be converted to TypeScript. It is a mistake, in my opinion to assume that JavaScript and TypeScript are interchangeable.

@lance Can you please describe more? The library will still be compatible with JavaScript. I strongly recommend using TypeScript. What specific concerns do you have?

@grant @fabiojose I would like to request that this repository NOT be converted to TypeScript. It is a mistake, in my opinion to assume that JavaScript and TypeScript are interchangeable.

@lance there is a channel at slack. Join us to discuss this issue. More heads, more thoughts
#cloudeventssdk

@grant I understand that the library can be used with Node.js if it's TypeScript and I'm fine with adding types to this module. But I personally do not use TypeScript and don't particularly want to completely change my projects to use TypeScript just to parse CloudEvents, whether or not you strongly recommend that I do. I also will stop contributing to this project if it's converted to TypeScript and instead write another Node.js module. Of course, my contributions can be replaced - and there won't be any hard feelings - but over the last month I am by far the most prolific contributor here.
¯_(ツ)_/¯

@fabiojose I've sent a request to join the Slack

My TS knowledge still limited to continue contributing

Hi Lance, I think there may be some confusion, which is completely understandable.
You don't need to change any of your projects to use TypeScript. We don't expect anybody to do that. I assume many projects will just use vanilla Node now and in the future.
I understand as a personal (and large) contributor to this project who might not be using TypeScript, it might seem like we are coming from left-field asking for this. I thought the same before I used TypeScript too.
JavaScript is valid TypeScript. It's a strict superset. The first step would be very simple:

Change .js files to .ts
Add a watch/build step (npm run build)

All contributors can use Node as they have been used to, but need to run the watch command. There may be some cases where we will want to add types or interfaces, but I don't think that will be an issue.

Hi @grant - just to be clear, I have used TypeScript and understand that it's valid JavaScript.
However

Change .js files to .ts
Add a watch/build step (npm run build)

This is exactly what I object to. That and the verbose non-intuitive syntax of TypeScript. And the added code size.
With good linting, proper use of class, private fields, and complete test coverage (all things any modern JavaScript project should have) the benefits of TypeScript just don't seem very persuasive to me.
Respectfully, I understand that you may like TypeScript more than vanilla JavaScript. But I don't accept that it's a de facto improvement and I have not seen any real justification for completely rewriting this module. I will be right there with you in saying that the module needs improvement. But this is not the path I want to take in order to do that.

Just wanted to add... I realize that in some circles this is not a popular opinion. I don't mean to be abrasive about it. I'm just a purist and do not believe TypeScript is by default an improvement.

Can you be more specific as to what you object? I said we don't have to use any special TS syntax to start. The code size would not be different, there is no impact on user-executed code. Do you not want to have a different file extension? Do you not want to run the watch command?
If I told you that Google, Microsoft, Lyft, Slack, Asana, and others use TypeScript because of clear benefits with tooling, testability, refactorability, navigation, would that make a difference?
In the above comment, we're threatening to stop contributing to this project and saying that we're the most prolific contributor here. That isn't what the CloudEvent format and CNCF community is about.
Are there specific incompatibilities at Red Hat that this would cause? Is it just personal opinion? If a majority of folks wanted TS support, would you allow it?

Let's be clear - I can't allow or disallow anything. I'm just a community contributor who has become invested in this project. I don't have write permission on this repository or any level of contributor status other than as a community member. I haven't even submitted an issue asking to be added as a collaborator.
I apologize for my apparent self-aggrandizement as the most prolific contributor in the last month. It had seemed to me that the project was not being very well maintained, so I jumped in and started contributing code. And while my contributions have been slow to land, I feel invested in the project and would like to make it successful. I too would like to create a widely used and high quality open source community tool. I'm not unfamiliar with the paradigm.
It was not meant as a threat that I would stop contributing. It's just the way it is. I don't have to use this module. I would like to, but if it changes to TypeScript I will likely move away from it. I'm sorry if it came across as threatening.
I know that lots of big companies use TypeScript. Lots of big companies use COBOL. This argument doesn't persuade me.
Regarding Red Hat... I'm not speaking for the company, though I am using this module in support of our objectives. I know that among the peers in my immediate circle at Red Hat, most prefer not to use TypeScript. I don't know what you mean by "a majority of folks". It's not clear that many people are using this module. So if there are 4 people in favor of TypeScript and myself against it, I guess I'm out numbered.
Now, just in case I misunderstand what you are saying, I should be clear. I have no objection to declaring and publishing types such as this: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/opossum/index.d.ts#L5. What I object to is writing my code like this: https://github.com/GoogleCloudPlatform/functions-framework-nodejs/blob/master/src/invoker.ts.

OK, thanks for the response. And thanks for your contributions.
I hope we don't have unreadable code. I hope we have a more usable module with active developers like yourself that can improve the CloudEvent ecosystem.
There are a few logistics/issues we need to solve before adding TypeScript type support anyhow. I'm curious as to how you're using this module currently, and perhaps how it could be improved. I'll be keeping the usage of this module in https://github.com/boson-project/faas-js-runtime in mind.

@grant good deal. I don’t want unreadable code either. I want this to be high quality idiomatic JavaScript and of course, with Typescript type support. :) IMO one good improvement might be this: https://github.com/cloudevents/sdk-javascript/issues/65

@lance I've been only recently picking up typescript so please excuse my ignorance.  Is there an automated process in opossum (or an example elsewhere) that validates that as changes occur that the type declarations do not drift or more pointedly that the typescript consumers aren't caught out?

@lance I've been only recently picking up typescript so please excuse my ignorance. Is there an automated process in opossum (or an example elsewhere) that validates that as changes occur that the type declarations do not drift or more pointedly that the typescript consumers aren't caught out?

The problem with separate type declarations is that they are not updated with the source code.
This is what was done in the repo before, but they were not updated with the source. Thus, the types were inaccurate and unusable. See https://github.com/cloudevents/sdk-javascript/issues/9#issuecomment-550335296
As this repo changes too much, the only option would be to use TypeScript to generate types.

Thanks @grant I hear that concern.  If the automated validation means I am asking about was in place, I wouldn't expect type drift to have occurred.

@grant there is not anything automated for opossum type generation. I agree this is not ideal. The types for that module are mostly maintained by external contributors who have an interest in using TS.
I just skimmed this article, but it looks promising. https://dev.to/open-wc/generating-typescript-definition-files-from-javascript-5bp2
They are auto generating types from JavaScript functions which contain valid jsdoc (which we of course need anyway).

FWIW - I would like ultimately for the user-facing API to be a little more stable and expose far less. Ideally, we have this:
const { CloudEvent, HTTPReceiver, HTTPEmitter } = require('cloudevents-sdk');

There's not much more that a developer needs to be concerned with IMO. All of the parsers and unmarshallers and all of that are internal to the module and don't need to be exposed. Keeping the API footprint small and clean should also help quite a bit.

Hi @lance - pretty sure it was me that asked about automation ;D  Would you be willing to add the automation for validating that drift doesn't happen?  It appears that the relevant PR called out by that article has landed (it targeted 3.7 but 3.8 is out and 3.9 is RC).  Is it working?  If so is this really going to provide the same level of type validation or does it move responsibility off of the compiler to the maintainers and reviewers?
@grant it's not clear to me that js-docs are less arduous than typescript but if this solution generated the necessary *.d.ts files and validation of type declaration and safety were part of an automated CI process run against all PRs in this repo, would it satisfy your needs if not preferences?

Unfortunately JSDoc comments don't satisfy deep accurate autocompletion or other benefits of TypeScript such as optional static typing. Besides, code comments aren't enforced or always complete/accurate. Generating .d.ts files doesn't sound great even if it could be done.
Converting to ES6 gets some autocompletion, but not as thorough or deep as TypeScript. The IDE experience is awesome. We could dramatically reduce tests while ensuring increased safety. Example in TS:

Again, we don't need to change anything besides renaming .js files to .ts to get this benefit.

@erikerikson sorry for the misattribution! :)
@grant JSDoc can be enforced with eslint. We already have a very basic linting rule that enforces valid JSDoc if JSDoc exists. This can be changed to require JSDoc. I think we'd want to clarify exactly what API should be exposed and only enforce it on those files. But I think it might be as difficult as you imagine to enforce this if we keep the surface area of the API much smaller than it is today.

@lance Yes, JSDoc can be enforced, and we can write the params twice, once in docs and once in code. Some completion will work but not all, and there aren't great linters. We could add tooling and use/write/maintain custom IDE plug-ins.
With JS, we can't rename variables, have deep autocompletion or autocompletion of objects, or move functions between files. If anyone has a solution using pure JS rather than TS, I'm all ears!
JS is OK for small projects, but CloudEvents and Node are used by large projects.
Additionally, types are super important for this project as the CloudEvent spec is very specific and has multiple versions.
The TypeScript's and Code's Twitter has loads of benefits and gifs of IDE support if anyone isn't convinced:
https://twitter.com/typescript
https://twitter.com/code
If you use VS Code, you're using TypeScript too. The IDE does it's best with plain JS autocompletion, but it's not as great.

Anyways, we can't convince everyone to use TS. Big Javascript users like Google, Microsoft, Netflix have used it for 3+ years at least and given many supportive talks. There are hundreds of supporting blogposts too. It's one of the world's most loved programming languages. This GitHub issue is the largest issue in the repo and it directly asks for TypeScript support – so I'm not sure why we don't just do it.
As Lance mentioned on Slack, code talks. See #137. I don't think it'll interrupt anyone's dev flow too much and could be merged.
If we can't make progress on that PR, it's best to just create a new project at this point, where we can solve other issues such as idiomatic non-Java-like builders for CloudEvent objects. This can be done after the CNCF call next week.

JS is OK for small projects, but CloudEvents and Node are used by large projects.
Additionally, types are super important for this project as the CloudEvent spec is very specific and has multiple versions.

Super important points.
Typescript, because of its inherent typing, is:

more maintainable,
reduces bugs (estimation that typing results in a 15% decrease of bugs),
better for collaboration,
better for 3pp use.

Typescript with generated type declarations, please.

@cwallsfdc

Typescript, because of its inherent typing, is:
more maintainable,

Do you have empirical data showing this? And by whom? I mean, I'm pretty good at maintaining JS projects - a personal project of mine gets about 34k downloads a week from NPM, has a very low bug count, several active maintainers, etc... Your statement is subjective.

reduces bugs (estimation that typing results in a 15% decrease of bugs),

Again, let's see some empirical data. I'm not convinced. Here's a good article covering that issue (and many others with TS vs. JS).

Type safety doesn’t seem to make a big difference. TypeScript proponents frequently talk about the benefits of type safety, but there is little evidence that type safety makes much difference (really, static types seem to have very little impact) to production bug density. This is important because code review and TDD make a very big difference (40% — 80% for TDD alone). Pair TDD with design review, spec review, and code review, and you’re looking at 90%+ reductions in bug density. Many of those processes (particularly TDD) are capable of catching all of the same class of bugs that TypeScript catches, as well as many bugs that TypeScript will never be able to catch.

better for collaboration,

According to whom? Everyone that I work with who is currently contributing to this repository would probably disagree. None of them are TS developers. Again, this is highly subjective.

better for 3pp use.

I'll say this is highly subjective - again. There is some benefit in developer tooling, but it's not huge. Also from the article linked above.

The development tool choice isn’t TypeScript vs native JavaScript and no tooling. It’s between TypeScript and the entire rich ecosystem of JavaScript developer tools. Native JavaScript autocomplete and error detection gets you 80% — 90% of the benefits of TypeScript when you use autocomplete, type inference, and lint tooling. When you’re running type inference, and you use ES6 default parameters, you get type hints just like you would with type-annotated TypeScript code.

Typescript with generated type declarations, please.

We are working on a solution with @grant's PR. https://github.com/cloudevents/sdk-javascript/pull/137
But you need to understand that TypeScript is not JavaScript, and asking the maintainers to completely change the repository to be written fully in TS is just too much to ask, in my opinion. That is, unless there are a lot of contributors who know and love to write TS. At this point, there is one. All of the rest are pure JavaScript developers. So, I encourage you to become more actively involved in code contributions if you feel so strongly about it.

@lance regarding

Everyone that I work with who is currently contributing to this repository would probably disagree.

and

asking the maintainers to completely change the repository to be written fully in TS is just too much to ask

I am not a maintainer here so I am not attempting to assert a preference but I have been a part of CloudEvents for sometime and have written a fair bit of JavaScript over recent years.  In response to these particular comments of yours I'd like to call out that there was a vote in this issue and the outcome seems to support switching.  All stakeholders may not have participated.  However, if we weighted by commits, fabiojose's would be the only vote that matters and they seem to be in support.
I appreciate that the language switch strongly contradicts your preference and I can empathize with the pain of having a project you are invested in changed in ways that you dislike (I have left positions and taken breaks from the industry over this sort of thing).  However, I bring up the vote and relative investments because asserting that it is too much to ask for a language expansion (the superset thing) from the maintainers seems strongly contradicted by the fact that the most prolific maintainer brought up the vote and so far along with other committers appears to support the change.
I wouldn't care or spend my attention on this conflict except that this is an official repository of CloudEvents and owned by the CNCF.  I am concerned that this conflict over personal preferences could likely lead to a confusing experience and unnecessary decisions for engineers who don't understand the implication of choices they didn't or shouldn't have to think about.  The costs and impacts of this project are those that will happen at scale across the industry.
It seems important that the group here can make this decision in a decisive but fair manner.  A vote from maintainers seems a reasonable approach and it was attempted.  So far yours is the single dissenting voice that I've read.  Perhaps other maintainers of the project you know would like to speak up against typescript?  Maybe you have alternative mechanisms to making the decision that you would like to suggest?

@erikerikson

I'd like to call out that there was a vote in this issue and the outcome seems to support switching

This vote occurred 9 months ago, prior to the release of 1.0, and garnered a total of 6 votes. Surely that can't be interpreted as a fair representation.
Fabio was quite active in the repository then, and I agree, at that time his was the only vote that matters. Today, however, he is not very active. Michele was a committer at the time but also has not been active in months. It does not appear to me that any of the remaining three voters have contributed at all, but I could be mistaken. In any case, if it was considered so important, I would assume that someone would have actually contributed code over the last nine months to make that happen. That was not the case.
Help me understand how switching to TypeScript is a benefit to the consumer of this SDK. As I see it, the benefits are mostly aimed at repository maintainers who are writing the code. For the end user, the main benefit is type checking in their IDE, which can be achieved through JSDoc and type definitions. In an effort to make a compromise, I have suggested these as alternatives and they were rejected. I don't think I'm being unreasonable. Frankly, I think Grant is.
Regarding personal preference, I guess I summed up my position pretty well on Slack.

I just don't know what else to say. It's true, I will not maintain a repository in a language that I don't  use. TBQH, I haven't seen a single contribution to the repository from anyone pushing for  TypeScript by anyone except yourself [Grant]. If there were a lot of contributors doing so, it might be different. But that's not the case. I have been fixing bugs, improving the API, updating documentation and preparing a release and honestly, this conversation is quite tedious.
I have tried to find common ground - generated type definitions, your existing PR. I don't think I'm being unreasonable.
I am not working on this just for fun. It's part of my job at Red Hat, and we will be using this repository as a part of a product we are developing to sell to our customers. I and the others in my group who are currently contributing to the repository are pure JS developers. If it's converted to TypeScript we cannot continue to contribute to it because we cannot support it for our customers.
I believe in community. I just don't believe in a handful of people coming in and completely changing an existing project because that's just what they feel like doing. Please, continue to contribute to the project. As it evolves, it might steer in your direction. But days on end of discussion around a complete overhaul is a waste of time.

If you want to call another vote - by current contributors - that's fine with me. I'm not convinced that a nine month old poll by with 6 voters, half of whom have not contributed code, is reasonable.

Thank you for pointing out the timestamp on the vote.  Thank you also for sharing a richer picture of the contribution history than I can get on the repo listing.
My concern is the splitting of the repository as was agreed on the weekly call.  Having two official JavaScript SDKs, one written in vanilla JavaScript and the other in TypeScript would result in two npm packages and two sets of documentation.  Contradictory questions and answers about the official CloudEvents JavaScript would be likely on stackoverflow and the like.  I imagine that we can all predict some of the funny (and not so) ways that could play out.  Unfortunately, I think this perhaps raises the stakes here.  I apologize for adding complexity to the discussion.
So long as the concerns of both communities are satisfied in a dependable manner, I don't feel I get an assertion on the matter despite a prediction that it may well impact me latter.
To be frank myself, I would agree that there has been little steelmanning in this discussion and that beliefs have been written from an assumption of their universal acceptance as truth.  In the end, this is making the whole discussion harder and less efficient for everyone.

Looking into CloudEvents system as a newbie the first thing I looked at was this sdk-javascript repository, and my first impression was this is a bummer it is not typescript as it would bring a clean type.
I have no rights or voice as I did not contribute to this repo at all, so just adding my 2 cents. As @grant said, moving to Typescript is not a revolution and could probably benefit everyone. If some help are needed I might be able to help a bit.
Reading @erikerikson last comment, splitting repo seems like a bad idea to me.

@erikerikson Thanks for considering my point of view. I too want to avoid splintering this community. Code talks, in my opinion, and if people really want to make change, they are empowered to do so through the wonder of FOSS. This repository is open to pull requests, and I don't think something reasonable will just be dismissed out of hand. Small steps towards stated end goals makes sense and is good. But I don't want that end goal to be "let's change it to TypeScript". It should rather be, "let's make this repository great for end users like @loopingz by ensuring they have type support in commonly used IDE and development tools". Those goals may seem the same, but they are not. There are many ways to get to the second without requiring the first.
I want this repository to be a high quality example of FOSS. I want it to be well tested, documented, easy to use, accessible, work well with modern tooling, and make it so that TypeScript users like @loopingz feel good about it. All of that. I just don't think that simply converting to TypeScript gets us that. There's more than one way to shave a yak.
Rather than focus on changing the technology right now, I'd much rather focus on improving the code as it is today and evolve it over time to meet everyone's needs.

This vote occurred 9 months ago, prior to the release of 1.0, and garnered a total of 6 votes. Surely that can't be interpreted as a fair representation.

This is directly attacking the validity of a popular vote and is adding recency bias. CE 1.0 just came out recently and more vendors are joining CloudEvents. Saying there hasn't been that many contributors in the last few months should weight no meaning. We are building this SDK for end-users, not contributors.
Moreover, by commenting that another vote is fine by you, you're not suggesting an actual solution, just creating churn. Would you fully accept a popular vote? What would it take?
I'm pretty sure trying to use TypeScript will get rid of a lot of need for discussion. Can you please just try it? Please?
Your RedHat customers using @redhat/faas-js-runtime will be able to have autocompletion when creating/consuming CloudEvent objects, even if they use vanilla JavaScript. Missing CloudEvent object properties will linted with links to the source code. It will really benefit you and RedHat.
The alternatives mentioned aren't great:

JSDoc: Documentation gets old fast and is not 100% accurate. You can't rename variables for example.
Type Definitions: Please tell me about the type definitions and validation tool that you mention will solve this problem. Suggest in PRs to compromise. TypeScript is just one solution for type definitions that is popular.

I don't recall your generated type definitions as you mention.

All in all,
Lance, I recommend reading this if you have 5 minutes:
https://www.typescriptlang.org/v2/docs/handbook/typescript-in-5-minutes.html
We need everyone to be on board with adopting TypeScript to achieve the maximum benefit. It will positively impact thousands of developers in creating a great developer experience for Node developers consuming CloudEvents.

To make it more "real" I did migrate the whole repo to typescript: https://github.com/loopingz/sdk-javascript
For the sake of rapidity, I took a few shortcut (it compiles and requires a bit more to be cleaner, use your formatter etc)

I'm pretty sure trying to use TypeScript will get rid of a lot of need for discussion. Can you please just try it? Please?

@loopingz Wow! Thanks for doing this - I really do appreciate it. As @grant mentioned earlier, quoting me on Slack, code talks. I much prefer this approach over all of this discussion. I will try and pull your commit this weekend (or Monday at the latest) to play with it. And if you want to submit a pull request, that's totally fine.
As an aside, there are currently a few in-flight PRs that really should land in the next week. If you do submit a PR, there will be a few conflicts once these are on master. We're releasing 2.0.0 soon with some bug fixes and API improvements.

Yes, I can do PR next week, with a bit more time, was supposed to be offgrid for a few days :)
I think I've seen there were weekly calls, if it is open to public, I'll try to join. As in-person conversations are usually always easier.
No worries about adapting other PRs, please be aware this is a first pass, we should then add more type specifications etc. What is good with those switch JS to TS is that you can do it gradually to improve the overall project step-by-step.

@loopingz yes feel free to join the calls and slack. I haven't applied your commit yet, but read through the code changes and have some comments/questions on your fork. We can discuss there or in Slack.

For what its worth, It's possible to use JSdocs to generate full typescript types into [whatever].d.ts files
This means you can use vanilla JS, annotate with JS docs and typescript users get all the IDE autocompletion goodies. Everyone wins!? 😃
For an example of this see my analytics project. Using Jsdocs the build step reads them & generates typescript definition files. Additionally, the doc blocks are used to generate 99% of the docs site.

@DavidWells I discovered this recently, and commented on it above in the thread. How has it been using this?

I just skimmed this article, but it looks promising. https://dev.to/open-wc/generating-typescript-definition-files-from-javascript-5bp2 They are auto generating types from JavaScript functions which contain valid jsdoc (which we of course need anyway).

@lance the setup works great IMO. example
Basically, I get type checking in VSCode via JSdocs when working on the project and consumers of the project get IDE autocompletion. (From what I can tell the main benefits of using typescript).
Additionally, I get to use (IMO) more human-readable docs with inline doc blocks with usage examples etc. The doc blocks are used to automatically generate docs & keep them in sync. For example, this docblock generates the docs in github and on the site

@DavidWells that's great. I'm familiar with the benefits of JSDoc and whatever route we take, I think we need to address that in this repo. I guess what I'm curious about is whether this solution fully addresses the concerns voiced in this thread and how different/similar it would be from a maintainer's perspective as compared to what @loopingz has shown.

Using jsdoc to generate typescript types sounds a good idea but on the long run i would expect code to be updated with forgotten jsdoc block etc. That is why typescript came to life and why it is spreading that much.

Yeah, I guess it just depends on preference.
Personally, I prefer just javascript because there is a wider audience of developers who author code in JS. So in theory, the larger opportunity for OS contributions lies in pure JS. Additionally, I think Typescript has a larger learning curve and can be trickier for folks to pick up.
Both work and I have no dog in this fight 😃. Pros and cons both ways

I finally found time to read this whole thread! oy vey!  :-)
To make sure I understand things since (as I've said) I don't know TS at all and don't do anything with JS outside of a browser, early on in the thread it seemed like there were two concerns from @lance w.r.t. the proposed direction:
1 - it would require users of the SDK to rename their files form *.js to *.ts
2 - it would require users of the SDK to add a watch/build step
And, as I understand it, TS is a compiled language in the sense that it needs to be converted from TS to JS before it is executed (interpreted) at runtime.
Sound ok so far?
If so, I have just a couple of questions:

since TS is a superset of JS, would it make sense (or be possible) to have a JS SDK be leveraged by a TS user in a way that makes sense to them? Or would they expect things to be there (like static typing) that the JS SDK would not have?
Assuming a JS SDK wouldn't be a good fit for a TS user, would the TS SDK need (or want) to leverage the JS SDK code at all? Meaning, would it ever make sense for the TS SDK to be a layer on top of the JS SDK or is that just an extra layer without a purpose and the TS SDK would be better written to be a native CE processor?
If a layering approach makes no sense, which implies to me that there's basically no code sharing, would there be any benefit to both code bases being in the same repo? The only thing that comes to mind is a shared conceptual model/design but we (sort of) try to do that today across the various SDK already.

I'm guessing the answer to all 3 bullets is basically "no" which is why we landed on the "new SDK" decision. But I wanted to make sure I'm up to speed.
How far off am I?  :-)

I finally found time to read this whole thread! oy vey! :-)

Thanks for taking the time - and on a Friday night, even. :smile:

it seemed like there were two concerns from @lance w.r.t. the proposed direction:
1 - it would require users of the SDK to rename their files form *.js to *.ts
2 - it would require users of the SDK to add a watch/build step

Not really - those were concerns that were attributed to me by others. Really what I care about is maintainer productivity and the larger pool of potential contributors (and alienating existing contributors who have only recently started to submit code (including myself)).

And, as I understand it, TS is a compiled language in the sense that it needs to be converted from TS to JS before it is executed (interpreted) at runtime.

Correct.

since TS is a superset of JS, would it make sense (or be possible) to have a JS SDK be leveraged by a TS user in a way that makes sense to them?

Yes - see David's comment above. Personally, I think this is the best path forward for a possible migration to TypeScript in the future. This is the compromise I have recently suggested. I honestly do not want this community fractured and I'm trying to be open about this. My preference is pure JS. Clearly, that feeling is not universal. :yin_yang:. I personally would be most comfortable with a graduated approach using the methods suggested by David.
Concerns about doc comments drifting from implementation are valid, but there are ways to deal with this using tools and processes.

I have limited TS knowledge and I have no room for TS learning in my free time to be able to be comfortable in contributing.

1 - it would require users of the SDK to rename their files form *.js to *.ts
2 - it would require users of the SDK to add a watch/build step
Sound ok so far?

Yes. Those are the two main points, .ts files and running watch/build. Adding tools/processes on top of this is fine. I think another fear of developers is that TS has a steep learning curve (it does not, there is literally no difference if you only use JS features).
TypeScript is required for many projects including those at Google and Microsoft, hence my interest.
The best path forward is a separate implementation with TypeScript. If there is value in merging projects at a later point, that sounds fine.

@grant Can you explain the specifics of the Typescript requirement?  Are guaranteed to be correct typescript types are not enough?
The js=>ts renaming doesn't seem to be necessary with the proper tsconfig and the addition of watch/build using tsc and enforced by CI has largely been ceded.  Do I appear wrong on these points?  Insisting on these two points despite direct statement that they are not the concern is a curious behavior.
You seem to be implying that only JavaScript features would be used. I'm curious how you expect that could be affected. Do you expect contributors from across the internet to forgo using TypeScript features desire project conversion and labeling as typescript? Is there a mechanism you have in mind for enforcing that?  Are you willing to agree to it's use?

@grant Can you explain the specifics of the Typescript requirement? Are guaranteed to be correct typescript types are not enough?

Sure. As a developer:

I must know the exact properties of a CloudEvent before execution.
I must never see "undefined" is not a function or equivalent for SDK users.
I must have autocompletion in my developer tooling/IDE for CloudEvents.
I must be able to click to definition to see the source code of the SDK.
I must see linting errors in my code if I use the CloudEvent SDK incorrectly (i.e. invalid type).

There are a few projects that could use an SDK for CloudEvents in Node.
Here is an example project that could use the SDK with TypeScript:
Example at Google
https://www.npmjs.com/package/@google-cloud/functions-framework
It powers serverless functions for Google Cloud. We don't use this module to accept/parse HTTP requests with CloudEvents due to a few issues, one being lack of TS support.
We require autocompletion and static checks to ensure that the module is running correctly. It's vital for ensuring we don't crash our product for thousands of customers on a bad deploy. Many other companies use this superset language.
It's Literally Node
It's literally no different, please browse the code of the TypeScript version:
https://github.com/loopingz/sdk-javascript
This is the literal code change that we're talking about...
It's Incremental
You don't need to learn a new language. We can enforce not using non-JS features.
It's an industry-wide standard that you're probably using right now
If someone was to magically enforce types and IDE integration with types that are not from TypeScript, that's fine. That's really the point of TypeScript though. There is a whole ecosystem and company support around TypeScript.
Example players supporting TS: https://tsconf.io/
I can't find any project that does anything similar.
I assume many people use VS Code for code editing right? That heavily uses TypeScript.
Other Questions

The js=>ts renaming doesn't seem to be necessary with the proper tsconfig and the addition of watch/build using tsc and enforced by CI has largely been ceded. Do I appear wrong on these points? Insisting on these two points despite direct statement that they are not the concern is a curious behavior.

Editors like VS Code will do it's best with just js files or just a tsconfig. You're really using TypeScript under-the-hood. At that point, you're really just avoiding the filename rename for some reason. 🤷

You seem to be implying that only JavaScript features would be used. I'm curious how you expect that could be affected. Do you expect contributors from across the internet to forgo using TypeScript features despite project conversion and labeling as typescript? Is there a mechanism you have in mind for enforcing that? Are you willing to agree to it's use?

I am saying that the main issue we're facing is the fear of change. We don't have to change any of the JavaScript if we don't want to to use TypeScript. There aren't that many contributors to this project for us to know to not accept PRs with extra TS features. We don't even consistently use ES6. I'm willing to agree on not using TypeScript features and we can add a simple lint file to enforce this via tslint.

 :-) As I brought up the concern in last week's call and now will say more strongly... I'm against having two separate, "official" "Javascript" sdks. That's just plain bad optics and makes for confusion, bugs, interop, support, etc. issues for users/consumers/providers of CE.

If I understand the camps' positions, @loopingz's code translation and some simple policies such as the tslint enforcement seem like a fair place to start so that we can remain as single JS SDK for CE. As someone who has no personal stake in the pure-JS vs. TS approach, I personally hope that people in the various camps are willing to at least try a joint approach openly before splitting into two separate, competing efforts.

As I brought up the concern in last week's call and now will say more strongly... I'm against having two separate, "official" "Javascript" sdks.

Hi @johnm, thanks for your opinion, but there are a couple issues. I literally cannot use this project unless it fully supports TypeScript. I oppose two separate JS-like repos too on the surface. I'm happy to merge separate repos if possible.
What do you expect me to do? This is a deal-blocker.
We currently have separate efforts, literal code duplication already, since there is no TypeScript support.
I'm obviously not as happy to continue a separate effort outside of a this repo or outside of this GitHub org.

@grant

I am saying that the main issue we're facing is the fear of change.

Two concerns I have heard are exclusion (or even just reduced welcome) and a potentially reduced contributor pool and thereby speed of improvement and community inclusion.
I understand that typescript is a superset and have indicated personal comfort with it (by admitting use).  To be transparent I would welcome a full transition an use of typescript constructs personally but my personal mores are unimportant in this case.  Depending on how we introduce typescript (if we do at all) we could create externalities.  This includes factors such as a subset of the population seeing unexpected constructs and be put off regardless of what size the learning curve might be.
Thank you for sharing the ability of tslint to enforce sticking to core JavaScript.  I'm curious if using that sufficient compromise for those who would like to stick with vanilla JavaScript (@lance or anyone else?).  I'm also a bit mystified by the assertion that the technical/concrete requirements would care at all about a file name.  If we look at loopingz's repo there are a couple further changes in it but they also seem pretty reasonably limited.

What do you expect me to do? This is a deal-blocker.

It turns out that (as a stand in for an important subset of users) your needs matter too.  What we are talking through are the deal-making constraints and options.  I apologize that my ignorance is forcing me to ask you to explain options and a bit of how our potential choices interact and what the choices available to us are.  I can imagine it is a little frustrating but I can only be where I am, please apply patience as you can.

As I brought up the concern in last week's call and now will say more strongly... I'm against having two separate, "official" "Javascript" sdks.

Hi @johnm, thanks for your opinion, but there are a couple issues. I literally cannot use this project unless it fully supports TypeScript. I oppose two separate JS-like repos too on the surface. I'm happy to merge separate repos if possible.
What do you expect me to do? This is a deal-blocker.
We currently have separate efforts, literal code duplication already, since there is no TypeScript support.
I'm obviously not as happy to continue a separate effort outside of a this repo or outside of this GitHub org.

Hm... Did you respond before reading my second comment? I hope that made clear, as I also commented in the call, was that it seems that there's a combined approach place to come together other.  Based on that, are there still deal breakers?

Well, thanks for all the replies and trying to figure this out @erikerikson.
Sorry @johnm, I was reacting a bit. This issue has been open for over a year with hundreds of commits to this project directly to master and no progress on issues like this one despite PRs, forks, Slack discussions, calls, etc. The comment of immediately positioning against making progress on this issue via separate repos was surprising and did not suggest a way forward.

38% of bugs at Airbnb could have been prevented by TypeScript according to postmortem analysis

Sorry @johnm, I was reacting a bit. This issue has been open for over a year with hundreds of commits to this project directly to master and no progress on issues like this one despite PRs, forks, Slack discussions, calls, etc. The comment of immediately positioning against making progress on this issue via separate repos was surprising and did not suggest a way forward.

No worries, I understand the frustration as I've been in similar situations previously.
FWIW, I separated the two different aspects on purpose. There are the problems at technology level but also at the project level (of the impact on the users/etc). I think the context of the project should be keep in mind when dealing with the tradeoffs in making the technology decisions.

38% of bugs at Airbnb could have been prevented by TypeScript according to postmortem analysis
To type or not to type: quantifying detectable bugs in JavaScript

May I come in and talk with you about our strongly typed savior, Rust & Wasm?  ;-) :-)

I must know the exact properties of a CloudEvent before execution.
I must never see "undefined" is not a function or equivalent for SDK users.
I must have autocompletion in my developer tooling/IDE for CloudEvents.
I must be able to click to definition to see the source code of the SDK.
I must see linting errors in my code if I use the CloudEvent SDK incorrectly (i.e. invalid type).

I was under the belief that using tsc and JSDoc would ensure that all of this is possible. Is that not the case?

Editors like VS Code will do it's best with just js files or just a tsconfig. You're really using TypeScript under-the-hood. At that point, you're really just avoiding the filename rename for some reason.

If type checking is enabled with tsc and there is a valid tsconfig, then VSCode should be satisfied, I think. I've recently been experimenting with this on my fork, and have found that it's quite effective.

I am saying that the main issue we're facing is the fear of change.

I might say reluctance to change. There are existing contributors (including myself) who are reluctant to switch fully to TS for a number of reasons. But I don't know that you are representing them in good faith. A reduced contributor pool and alienation of existing contributors are what I care most about. I really don't like the required transpilation stage in order to actually have a JavaScript engine be capable of reading my code, but I can live with that, I suppose. I do like the fact that tslint can enforce pure JS. But I wonder then, what's the point of actually converting to TS then if we can achieve the user-facing goals (knowing the properties of a CE, autocompletion, linting, etc)?
As @johnm has suggested, I would like to consider a path forward that starts small, using tsc to check the code, jsdoc to enable both IDE autocomplete and help tsc, and type declaration generation. Do this with an eye towards eventually moving to TS when this whole thing has simmered down a bit. I understand that there are potential benefits to TS. But there are reasons to take it slowly. I would like to think that this is a fair compromise.
To be quite honest, I would be surprise if Google would immediately start using this project if we did nothing but switch to TypeScript by changing file names and adding a watch command. Those first compromising steps seem necessary in any case.
Rather than a switch to TypeScript, my most pressing concerns are:

Reduce the surface area of the API to be much simpler, e.g. `const { CloudEvent, HTTPEmitter, HTTPReceiver } = require('cloudevents-sdk');
Add JSDoc to the entire public facing API (those classes above)
Design the API so that it is more consistent with the spec
Release 2.0.0 soon.

Honestly, I think these add much more value than renaming a bunch of files. I'd like to focus on these before making any major repository-wide changes if possible.

tsc is just a tool to transpile TypeScript to JavaScript.
One of the big point of TypeScript is to not have to duplicate your code inside of docs. Right now we don't have many comments in the code. The suggestion here is to add JSDoc and annotate types everywhere. That's going to create a lot of boilerplate.
There are 2 options:

Add JSDoc everywhere. Keep them up-to-date with refactors.
Rename files from .js to .ts and automatically understand types (even without annotations).

The above comment chooses option 1. I'm suggesting 2.
Again, switching to TypeScript is not a big change that will prevent you from having to write all that JSDoc.

To be quite honest, I would be surprised if Google immediately started using this project if we did nothing but switch to TypeScript by changing file names and adding a watch command. Those first compromising steps seem necessary in any case.

I literally work for Google, for Events, and have said multiple times I'd use this module if it was useful and supported TypeScript. See https://github.com/cloudevents/sdk-javascript/issues/9#issuecomment-518360425

Fixed in: https://github.com/cloudevents/sdk-javascript/pull/155


Is it a bug or my mistake?

this problem can reproduce on use python file call this script.
In Splash-Jupyter no problem.
In Http-UI has this problem.
function main(splash)
   splash:on_request(function(request)
      string.match("abcdef123", "%d+")
   end)
   splash:go('http://www.example.com')
end

In splash.server log, there is an error:
2016-03-18 17:05:12.775632 [network-manager] error in on_request callback
2016-03-18 17:05:12.776928 [network-manager] Traceback (most recent call last):
          File "/home/xiaoming/.pyenv/versions/py3-splash/lib/python3.4/site-packages/splash/network_manager.py", line 329, in _run_webpage_callbacks
            cb(*args)
          File "/home/xiaoming/.pyenv/versions/py3-splash/lib/python3.4/site-packages/splash/qtrender_lua.py", line 945, in _callback
            callback(req)
          File "lupa/_lupa.pyx", line 516, in lupa._lupa._LuaObject.__call__ (lupa/_lupa.c:8185)
          File "lupa/_lupa.pyx", line 1263, in lupa._lupa.call_lua (lupa/_lupa.c:18511)
          File "lupa/_lupa.pyx", line 1272, in lupa._lupa.execute_lua_call (lupa/_lupa.c:18624)
          File "lupa/_lupa.pyx", line 1225, in lupa._lupa.raise_lua_error (lupa/_lupa.c:17930)
        lupa._lupa.LuaError: [string "..."]:4: attempt to call field 'match' (a nil value)

Hi @genius001
string.match is disabled in the sandbox https://github.com/scrapinghub/splash/blob/480c74bf4a0cb7bc484c986303ebec529f19dea4/splash/lua_modules/sandbox.lua#L19
Not sure why since string.find is allowed...

@Youwotma hm, string.find also has pathological cases which can't be caught by a sandbox, maybe we should disable it as well

Thanks.  @Youwotma @kmike


WAL-2484: Set JWT in cookie

Description
Set the JWT in a cookie for the passkeys server to consume.
Crossbit-main PR: https://github.com/Paella-Labs/crossbit-main/pull/13853
Test plan
Creating a user in the scw_demo page.

Closing as we are not moving forward with this approach


Undertow 1.3.0.Beta2

Linux Build 2011 is now running using a merge of 6bf94cf3b3a39b4b6a9c0f89591113139d934cf0

Windows Build 1557 is now running using a merge of 6bf94cf3b3a39b4b6a9c0f89591113139d934cf0

Core - Full Integration Build 1150 is now running using a merge of 6bf94cf3b3a39b4b6a9c0f89591113139d934cf0

Core - Full Integration Build 1150 outcome was FAILURE using a merge of 6bf94cf3b3a39b4b6a9c0f89591113139d934cf0
Summary: Exit code 1 (new) Build time: 0:01:00
Build problems:
Process exited with code 1

Linux Build 2011 outcome was FAILURE using a merge of 6bf94cf3b3a39b4b6a9c0f89591113139d934cf0
Summary: Tests passed: 1053, ignored: 6; exit code 1 (new) Build time: 0:01:30
Build problems:
Process exited with code 1

Windows Build 1557 outcome was FAILURE using a merge of 6bf94cf3b3a39b4b6a9c0f89591113139d934cf0
Summary: Tests passed: 1053, ignored: 6; exit code 1 (new) Build time: 0:01:43
Build problems:
Process exited with code 1

Linux Build 2012 is now running using a merge of f5db05aba60410bad0e0d14a82e847ba349ff6b9

Core - Full Integration Build 1151 is now running using a merge of f5db05aba60410bad0e0d14a82e847ba349ff6b9

Windows Build 1558 is now running using a merge of f5db05aba60410bad0e0d14a82e847ba349ff6b9

Windows Build 1558 outcome was SUCCESS using a merge of f5db05aba60410bad0e0d14a82e847ba349ff6b9
Summary: Tests passed: 3211, ignored: 71 Build time: 0:22:45

Linux Build 2012 outcome was SUCCESS using a merge of f5db05aba60410bad0e0d14a82e847ba349ff6b9
Summary: Tests passed: 3211, ignored: 71 Build time: 0:25:34

Core - Full Integration Build 1151 outcome was FAILURE using a merge of f5db05aba60410bad0e0d14a82e847ba349ff6b9
Summary: Tests failed: 2 (2 new), passed: 2878, ignored: 395 Build time: 0:48:02
Build problems:
Failed tests detected
Failed tests
org.jboss.as.test.integration.messaging.mgmt.ConnectionFactoryManagementTestCase.testWriteDiscoveryGroupAttributeWhenConnectorIsAlreadyDefined: <no details avaliable>

org.jboss.as.test.integration.ejb.timerservice.mgmt.TimerManagementTestCase.testSuspendAndActivate: <no details avaliable>

retest this please

Windows Build 1564 is now running using a merge of f5db05aba60410bad0e0d14a82e847ba349ff6b9

Linux Build 2018 is now running using a merge of f5db05aba60410bad0e0d14a82e847ba349ff6b9

Core - Full Integration Build 1157 is now running using a merge of f5db05aba60410bad0e0d14a82e847ba349ff6b9

Windows Build 1564 outcome was SUCCESS using a merge of f5db05aba60410bad0e0d14a82e847ba349ff6b9
Summary: Tests passed: 3212, ignored: 71 Build time: 0:22:42

Linux Build 2018 outcome was SUCCESS using a merge of f5db05aba60410bad0e0d14a82e847ba349ff6b9
Summary: Tests passed: 3212, ignored: 71 Build time: 0:26:17

Core - Full Integration Build 1157 outcome was FAILURE using a merge of f5db05aba60410bad0e0d14a82e847ba349ff6b9
Summary: Tests failed: 3 (3 new), passed: 2874, ignored: 395, muted: 3 Build time: 0:52:42
Build problems:
Failed tests detected
Failed tests
org.jboss.as.test.integration.ejb.mdb.dynamic.DynamicMessageListenerTestCase.test1: <no details avaliable>

org.jboss.as.test.integration.ejb.remote.client.api.tx.EJBClientUserTransactionTestCase.testBatchOperationsInTx: <no details avaliable>

org.jboss.as.test.clustering.cluster.sso.ClusteredSingleSignOnTestCase(SYNC-tcp).testNoAuthSingleSignOn: <no details avaliable>

Retest this please

Core - Full Integration Build 1167 is now running using a merge of f5db05aba60410bad0e0d14a82e847ba349ff6b9

Linux Build 2029 is now running using a merge of f5db05aba60410bad0e0d14a82e847ba349ff6b9

Windows Build 1573 is now running using a merge of f5db05aba60410bad0e0d14a82e847ba349ff6b9

Windows Build 1573 outcome was SUCCESS using a merge of f5db05aba60410bad0e0d14a82e847ba349ff6b9
Summary: Tests passed: 3212, ignored: 71 Build time: 0:25:44

Linux Build 2029 outcome was SUCCESS using a merge of f5db05aba60410bad0e0d14a82e847ba349ff6b9
Summary: Tests passed: 3212, ignored: 71 Build time: 0:27:33

Core - Full Integration Build 1167 outcome was FAILURE using a merge of f5db05aba60410bad0e0d14a82e847ba349ff6b9
Summary: Execution timeout (new); tests failed: 3 (2 new), passed: 2876, ignored: 395, muted: 1 Build time: 1:42:40
Build problems:
Failed tests detected
Execution timeout
Failed tests
org.jboss.as.test.integration.messaging.mgmt.JMSTopicManagementTestCase.removeJMSTopicRemovesAllMessages: <no details avaliable>

org.jboss.as.test.integration.ws.wsse.signencrypt.EJBSignEncryptTestCase.encryptedAndSignedRequest: <no details avaliable>

org.jboss.as.test.integration.ejb.mdb.dynamic.DynamicMessageListenerTestCase.test1: <no details avaliable>

@stuartwdouglas if you feel these failures are unrelated, you have my :+1:

Retest this please

Linux Build 2038 is now running using a merge of f5db05aba60410bad0e0d14a82e847ba349ff6b9

Core - Full Integration Build 1175 is now running using a merge of f5db05aba60410bad0e0d14a82e847ba349ff6b9

Windows Build 1581 is now running using a merge of f5db05aba60410bad0e0d14a82e847ba349ff6b9

Windows Build 1581 outcome was SUCCESS using a merge of f5db05aba60410bad0e0d14a82e847ba349ff6b9
Summary: Tests passed: 3224, ignored: 71 Build time: 0:22:50

Linux Build 2038 outcome was SUCCESS using a merge of f5db05aba60410bad0e0d14a82e847ba349ff6b9
Summary: Tests passed: 3224, ignored: 71 Build time: 0:25:22

Core - Full Integration Build 1175 outcome was SUCCESS using a merge of f5db05aba60410bad0e0d14a82e847ba349ff6b9
Summary: Tests passed: 2880, ignored: 395 Build time: 0:47:14


Allow installation of contentful/contentful ^7.0

Since this issue on contentful/contentful has been fixed, this library should be updated to also allow ^7.0 of that package to be installed so we can use it in projects on PHP 8.1 and above.

Thank you @svenluijten !


sbisw002's PR

In qutip/qutip#1956, sbisw002 presented lots of new feature for the lattice submodule.
It is not in mergable state and in the wrong repo, but it's a great reference as to what features we should be able to support with implementation example.

Sorry for the late reply. I look forward to working on this. Please comment/advise/help.


[KEP] Extend WaitForPodsReady config by .waitForAdmissionChecks field

What type of PR is this?
/kind feature

What this PR does / why we need it:
Describes API extension for WaitForPodsReady which expands it's functionality to AdmissionChecks, to prevent wasteful allocation of resources and starvation.
Which issue(s) this PR fixes:

Part of #3231
Special notes for your reviewer:
Does this PR introduce a user-facing change?

NONE

/assign @mimowo
cc @mwielgus

/cc
@mimowo @PBundyra Will this be marked as a must-have for the next release?
I need to prioritize features for the next releases on my side.

/cc
@mimowo @PBundyra Will this be marked as a must-have for the next release? I need to prioritize features for the next releases on my side.

It shouldn't block the release, but it's a strong nice-to-have

It shouldn't block the release, but it's a strong nice-to-have

I see. It seems that there are a few strong nice-to-have...


fix(environment): Create POSTGRES_DATABASE_NAME env variable

Fix #29

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 75.63%. Comparing base (78e8e5b) to head (c615515).

Additional details and impacted files
@@           Coverage Diff           @@
##             main      #30   +/-   ##
=======================================
  Coverage   75.63%   75.63%
=======================================
  Files          93       93
  Lines        1884     1884
  Branches      362      365    +3
=======================================
  Hits         1425     1425
  Misses        450      450
  Partials        9        9

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


release: v1.8.0

Hi Buddy - Subscene still not working, Please could you fix it it is the top subtitle service for non-English users.

@farmaher The tests are passing and even done manual testing for English and Non-English results for Movies and TVShows. It seems to work. However, there were two times that I received a 503 (Service Unavailable) response from Subscene, so I presume the Subscene website is having issues loading occasionally. Will add a simple retry logic for such cases.

I see there is another issue for Subscene, related to the TVShow searching and the meta for the season year, which is used for matching. Will look into it. Thanks for the report.

I tried V2.0 in search for Persian subtitles but no results on Subscene again. Please check these out HERE & HERE. These are the settings in KODI, HERE & HERE

@farmaher This was a specific Persian language issue. Fixed in v2.1.0.

Many thanks for fixing it, will give it a go.


heading-has-content incorrectly reported for heading tags with static content in React ES6 class components

We have seen some of our heading tags (e.g.
) reporting the jsx-a11y/heading-has-content error through ESLint; while others seem fine.  In both cases, the headings have valid static text content.
From our initial diagnosis it seems that it is only mis-reporting for our ES6 class-based React components, while the same use in Stateless Functional Components returns valid.
Here is the full ESLint error:

Headings must have content and the content must be accessible by a screen reader. (jsx-a11y/heading-has-content)

I've reduced this down to two simple examples - the class version reports the error while the function does not.
Stateless Functional Component
import React from 'react';

export default function TestFunction() {
  return
Hi
;
}

ES6 Class
import React, {Component} from 'react';

export default class TestClass extends Component {
  render() {
    return
Hi
;
  }
}

Based on version 6.0.2.

I believe this was fixed in https://github.com/evcohen/eslint-plugin-jsx-a11y/pull/437, but a version containing that fix hasn't been released yet.

I'm also seeing this with the anchor-has-content rule.

#437 should have fixed this for anchor-has-content as well as heading-has-content. That fix was introduced in v6.1.0
@openjck does it still happen in v6.1.0+?

Closing; will reopen if needed.

@qw-in this is fixed. Here's my commit upgrading the package and removing the lines that disabled these rules.
https://github.com/mozilla/ensemble/commit/5e01cde2eda1b0dd0aa70aae8bf9611a2b1837ec

This is still happening in v6.1.2 for us when header is used with static content.

@DavideDaniel the commit that fixes it is still unreleased.

@DavideDaniel can you file a new issue with repro code?


feat(aws_lambda.js): add support for API Gateway WebSocket

:tada: This PR is included in version 1.77.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


security-team: Add myself to security team

Description
As discussed offline with multiple team members (e.g. Joe, Andre, and Jarno), I would love to submit the request to join the security team, I believe that this will help to fulfill my other responsibility as cilium/proxy maintainers for any security patches.
One point worth noting is that I have been maintaining and upgrading the cilium/proxy repo for any security patches for the last few months. Being part of the security team will definitely help with some preparation in advance.
https://github.com/cilium/community/blob/main/CONTRIBUTOR-ROLES.md#security-team

For your review and approval @joestringer (as nominator) and @aanm (as existing security member).

Given that you've been shadowing @jrajahalme lately around security handling and releases for https://github.com/cilium/proxy, I think it is a natural next step to add you to the Security Response Team to assist with vulnerability report handling and to provide some additional redundancy in the skills coverage. Thanks again for your contributions to the Cilium project, I'm happy to nominate you :tada:


feat:H1005-L3 - Refund and Refund Sync for D-local

Type of Change

[ ] Bugfix
[ ] New feature
[x] Enhancement
[ ] Refactoring
[ ] Dependency updates

Description
Added Refund and Refund sync integration for dlocal
Additional Changes

[ ] This PR modifies the database schema
[ ] This PR modifies application configuration/environment variables

Motivation and Context
Dlocal integration
How did you test it?
cargo test --package router --test connectors -- dlocal --test-threads=1

Checklist

[ ] I formatted the code cargo +nightly fmt --all
[ ] I addressed lints thrown by cargo clippy
[ ] I reviewed submitted code
[ ] I added unit tests for my changes where possible
[ ] I added a CHANGELOG entry if applicable

Duplicate PR


chore: Add babel-preset-env

Playing around with the CLI, I don't think babel actually does anything unless you specify presets or plugins, which is weird and confusing 🤔
∫ michael ~/Documents/test-stuff/test-babel ∫
Σ yarn babel test.js
yarn run v1.22.0
warning package.json: No license field
$ /Users/michael/Documents/test-stuff/test-babel/node_modules/.bin/babel test.js
const hey = [...[1, 2, 3]];
console.log(hey);

✨  Done in 0.61s.

∫ michael ~/Documents/test-stuff/test-babel ∫
Σ yarn babel test.js --presets @babel/preset-env
yarn run v1.22.0
warning package.json: No license field
$ /Users/michael/Documents/test-stuff/test-babel/node_modules/.bin/babel test.js --presets @babel/preset-env
"use strict";

var hey = [1, 2, 3].concat();
console.log(hey);

✨  Done in 0.53s.

This targets node 10 (the lowest maintained LTS version of node) so if any new syntax does get used packwatch will still work with at least node 10.

Codecov Report

Merging #7 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master     #7   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files           1      1
  Lines          34     34
  Branches        5      5
=====================================
  Hits           34     34

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 432ce16...d8a7cbf. Read the comment docs.

:tada: This PR is included in version 2.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Support for providers outside of this codebase

🚀 Describe the new functionality needed
Something to consider for after our apis are stable and the ecosystem matures a bit - but keen to know your thoughts.
We probably don't have the capacity to support all providers; If we try to, we risk becoming the bottleneck of the ecosystem.
There will be a lot of providers that might not be a good fit to be supported within this codebase. E.g.,

OpenAI
Anthropic
Experimental implementations
Niche providers - e.g., https://github.com/meta-llama/llama-stack/pull/518

I personally have thought about building:

OpenAI inference provider - because it allows me to compare and experiment between models
Memory with BM25 search - to improve retrievals

But having it a part of this code-base means that the burden is on you guys to maintain it. Experimental implementations will mostly not work out - but a few could be very valuable. So it doesn't make much sense to be in this code base.
💡 Why is this needed? What if we don't build it?
If we allow the community to build these providers, then we'd be able to have the community drive it and have the best providers bubble up.
Users would be able to pick the best providers, if one isn't well supported then others can fork it. The good ones will accumulate stars and gradually over time we end up with a set of well maintained and quality providers.
Is this something that you guys have thought about? wdyt?

Even I have been thinking about this for a while now, because I think adding something like gpt models to a pretty robust agentic framework like llama-stack, will be quite a game changer honestly. This would obviously require changes in the llama models repo and llama stack repo both.

I personally have thought about building:
OpenAI inference provider - because it allows me to compare and experiment between models

See my PR https://github.com/meta-llama/llama-stack/pull/195 and @ashwinb's rationale for closing it. I'd love to pick it up again if the maintainers are open to it.

One of the key reasons to not add a blanket OpenAI-compat inference provider is what Ashwin articulated - there would be no way for us to test/showcase the "compliant providers" of llama models.
On the other hand, an OpenAI-specific inference provider seems useful to have for benchmark evals on OpenAI's models. Thoughts on just creating providers for closed models like OpenAI, Claude, Gemini?

Maybe we create "community-maintained" vs "Meta-maintained" providers?

^ Yeah I think this would be a good distinction. The community-maintained ones have no guarantees and can be a lot more experimental, less stable and we should communicate that's the case.
But definitely not something we should support until we see some demand for it and until our apis are stable but thought I would open this issue though to track. We'll know there's demand for it if:

we see: "Could we support X in Y provider? I've submitted a PR, but you guys haven't reviewed it/or vetoed it - I think it's super necessary or useful for Z use-case" but it doesn't make sense for us to support it.
The community submits more PRs to keep providers up to date than we have capacity for review and we see community members getting frustrated because of it.

wrt to creating providers for closed models like OpenAI, Claude, Gemini - I see early signs of demand for it:

"Focus on Llama Models" - probably the only downside I see so far
[1]

@cheesecake100201 has expressed interest above and I myself have gone through the pain of re-writing something in OpenAI so I can compare models.
I'm speculating that a big barrier for people in industry to adopt Llama-stack will be - "What if we want to use GPT-4 or Claude?" in the future? Devs would need to justify that risk to other stakeholders in their design docs before introducing llama-stack. Imo, being able to switch between providers would be a big selling point. E.g., "If we go with Llama-stack, we can easily switch between OpenAI, Anthropic and Fireworks"; it de-risks vendor lock-in.
@raghotham But what is Meta's stance on this, since Llama-stack is a Meta sponsored project - are there any concerns with adding support for models outside of Meta? (I'm imagining you'll need to justify this decision to other stakeholders). E.g., if users are using Llama-stack but for other models besides Llama - esp closed source models?
Imo, I think it makes sense from a long-term approach + Customer Obsession, if Llama-stack is the go-to framework then there's actually a lot of opportunity with that. Two analogies are:

VSCode is free and you can install other coding assistants, but the default is GitHub Co-pilot
Chrome is free and you can set whatever default search engine you want, but the default is Google

wdyt?


words, mostly.

Starting to get the wordage in there.  Also, changed the way some of the functions get imported.  It's that second sentence that might worry you a bit.  Yeehaw.

Great, refactoring those functions as imports seems good to me.


Fix wiki.centos.org links

Fix https://wiki.centos.org/FAQ/General -> 404
Avoid unnecessary web.archive.org links

@richlander

Those changes look good.
The 6.0+ pages are subject to being re-written. However, the upstream changes will resolve that once your change is accepted.

Looks good to me. Thanks!


Don't assume location of bash

Not all environments (NixOS, for example) put bash in /bin. It's more portable to use
/usr/bin/env bash, which looks up the location of bash dynamically. In
practice the location of the env command is fairly standardized.

Thanks for the patch. You're right.


Bring telemetry inside proxy

Description

Move telemetry inside proxy

Related Issue(s)

Fixes IDE-142
How to test

Documentation

/hold

Close to continue with https://github.com/gitpod-io/gitpod-vscode-desktop/pull/72


FCnt values incorrect

After the initialization of my node and it joined (otaa) the network...
if I use: ttnctl devices info my_DevEUI
I get for FCn:
FCntUp: 0
FCntDn: 0
That seems normal.
If my node send data (e.g. with a rn2483: "mac tx cnf 1 3939390A") I get
(after tapping again: ttnctl devices info my_DevEUI )
FCntUp: 0
FCntDn: 1
After that, if my node sends again data, I get
FCntUp: 1
FCntDn: 2

The frame counter up is normally handled by your device. Are you sure that your device isn't sending '0' as a first fcnt ? Because that's exactly what it looks like.

I will check.
Tks for your time and patience

After testing with The Things Uno, I can confirm that the first frame counter sent by the device is indeed 0


Vm visibility

Four changes:

made the official VM downloads more visible. People didn't notice the links and downloaded the third-party ones. Now it is more clearly separated.
added tooltips to the links on the install page.
removed the recommendation for the packages over the zip file.
removed the Amazon app store for the Android client.

makes sense :+1:


Fix documentation IDs

Fixed the IDs for the documents in 04-setup so
that they no longer use the usage- prefix.
The usage- prefix was incorrect for the
parent folder.
My original implementations included a prefix,
but I later removed prefixes as they are redundant in the URL, and provide no additional value. These instances of usage- should have been removed
anyways.

@it-hms Did you want to review before merge?


Unsafe SQL calls

Unsafe SQL calls
When making database calls, it's highly important to protect your code from SQL injection vulnerabilities. You need to update your code to use wpdb calls and prepare() with your queries to protect them.
Please review the following:
https://developer.wordpress.org/reference/classes/wpdb/#protect-queries-against-sql-injection-attacks
http://codex.wordpress.org/Data_Validation#Database
http://make.wordpress.org/core/2012/12/12/php-warning-missing-argument-2-for-wpdb-prepare/
http://ottopress.com/2013/better-know-a-vulnerability-sql-injection/
Example(s) from your plugin:
FILE: src/admin/db/send-data.php

LINE 58: ERROR Use placeholders and $wpdb->prepare(); found interpolated variable $table_name at "INSERT INTO
$table_name(pointer, probability) VALUES ('" (WordPress.DB.PreparedSQL.InterpolatedNotPrepared)
LINE 58: ERROR Use placeholders and $wpdb->prepare(); found $pointers (WordPress.DB.PreparedSQL.NotPrepared)
LINE 58: ERROR Use placeholders and $wpdb->prepare(); found $i (WordPress.DB.PreparedSQL.NotPrepared)
LINE 58: ERROR Use placeholders and $wpdb->prepare(); found $probability (WordPress.DB.PreparedSQL.NotPrepared)
LINE 58: ERROR Use placeholders and $wpdb->prepare(); found $i (WordPress.DB.PreparedSQL.NotPrepared)

56:  ········}·else·{
57:  ············for·($i·=·0;·$i·<·count($pointers)·;·$i++)·{

58:  ················$result·=·$wpdb->query("INSERT·INTO·$table_name(pointer,·probability)·VALUES·('".$pointers[$i]."',·'".$probability[$i]."')");
59:  ····
60:  ················if·(!$result)·{

https://stackoverflow.com/questions/60174/how-can-i-prevent-sql-injection-in-php