Added backend. Emailing the messages received from users.

Added a backend template using NodeJs. Packages used:

express
body-parser
nodemailer

It needs a proxy email address (most likely, Gmail Account). If Two-factor authentication is enabled for that Google Account, the authentication process through nodemailer changes. The instructions are provided in ./backend/app.js
Output:

Red censor is the proxy email address used for testing. Blue censor is the email address of the user. The email is to be received on<EMAIL_ADDRESS>hence "to" key of the mailData object in app.post() route has the value<EMAIL_ADDRESS>(For the output I used my own Gmail accounts).

Added a backend template using NodeJs. Packages used:

express
body-parser
nodemailer

It needs a proxy email address (most likely, Gmail Account). If Two-factor authentication is enabled for that Google Account, the authentication process through nodemailer changes. The instructions are provided in ./backend/app.js
Output:
Red censor is the proxy email address used for testing. Blue censor is the email address of the user. The email is to be received on<EMAIL_ADDRESS>hence "to" key of the mailData object in app.post() route has the value<EMAIL_ADDRESS>(For the output I used my own Gmail accounts).

Thaks for your PR, please join the package.json file too!

Sorry for the inconvenience. Forgot to push the second commit I did with a few changes. Here it is now

Sorry for the inconvenience. Forgot to push the second commit I did with a few changes. Here it is now

Hi buddy, you need to add your node_modules to your .gitgnore file before committing and making a PR,
I will close this PR, please submit another one with the right files.


⚠ Bofrost.at has degraded performance

In 7a20f3f, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1168 ms

Resolved: Bofrost.at performance has improved in aa2be4e after 1 hour, 12 minutes.


What's the point of having the IDateTime interface?

What's the point of having the IDateTime interface? The implementation MachineDateTime just calls DateTime.Now for the Now property.

You need it for Unit tests.
Sample: When you create an object you want to fill CreatedAt by the DateTime.UtcNow
The current DateTime is a kind of dependency on the environment.
How to write tests to CreatedAt?
The easiest way - create an IDateTime interface and mock it in tests.
And one more benefit - dependency on the IDateTime is explicit. You can see that this class depends on environment.

You need it for Unit tests.
Sample: When you create an object you want to fill CreatedAt by the DateTime.UtcNow
The current DateTime is a kind of dependency on the environment.
How to write tests to CreatedAt?
The easiest way - create an IDateTime interface and mock it in tests.
And one more benefit - dependency on the IDateTime is explicit. You can see that this class depends on environment.

Thank you so much.


[R-236] testset hard negatives

Describe the Feature
Use similarity to also give similar nodes for a given node so each question has a set of hard negatives against it
Why is the feature important for you?
Improve dataset.
Additional context
N/A
R-236

this is something we have been thinking for a while too - very important feature too
Thanks for proposing this @PrathamSoni 🙂
btw while we are developing would love to get some early feedback from you if possible - would you be able to help us with that Pratham?

Yes of course!

any updates on this


Allow to track last sign-in time of users

Related issue: https://github.com/owncloud/enterprise/issues/6726
To allow tracking new user signins we're are now emitting an UserSignedIn event from the proxy's account resolve middleware.
A goroutine, started as part of the graph service (the only service that might have write access to the idm database currently) consumes that event and updates a new LDAP attribute ocLastSignInTimestamp on the user object.
The PR does not yet expose the attribute on the users endpoint. Support for that will be added in a separate PR.

LGFM

Missing a description in the graph's README about this functionality...

Missing a description in the graph's README about this functionality...

The README is currently lacking ANY information about the user management related feature. IMO adding a single paragraph about the sign-in time tracking there without any additional context brings no additional value.
I am fine adding adding a more complete section about the user management features and related options. Including the features added with this PR. But I will work on that in a separate PR.

@rhafer Which release will this end up in?

It's not part of any release yet. It's only in master AFAICS

Should become part of 6.4.1


Sensor: Current Power needed

Hi!
Can we have the sensor that displays "current power" usage of heat pump? It is found under:
Einstellungen --> Informationen --> Anlagenstatus --> "Leistung Ist"
Cannot not see this yet, but need it, to calculate current COP.

Yes, good idea. It is calculations.Heat_Output.
May not be present in all firmware versions, or supported by all heat pumps though.

Thx! Current electrical power is measured and available in HomeAssistant :-)
I would build a template sensor and calculate current COP.
Daily COP and average COP can already be calculated using heat amount sensor. Only current missing.
Von meinem iPhone gesendet
Am 20.11.2022 um 19:50 schrieb Kars de Jong @.***>:

Yes, good idea. It is calculations.Heat_Output.
May not be present in all firmware versions, or supported by all heat pumps though.
—
Reply to this email directly, view it on GitHubhttps://github.com/BenPru/luxtronik/issues/30#issuecomment-1321212451, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABAAC4BIHDEOFFT62FNZPMLWJJXILANCNFSM6AAAAAASF57LAI.
You are receiving this because you authored the thread.Message ID: @.***>

added the sensor myself, seems to be working. I will open a pull request after some testing.

Pull request done!

Review done!

Can we close this ticket?


Finalising the 3D renderer

If there are any simple ways we could adjust features of the 3d rendering, e.g. the shininess/mattness of the material, that would be good to have in the setting drawer

Options I'm thinking:

[x] Disable lighting (actually looks surprisingly cool)
[ ] Gamma control (was previously 2.2, is currently 1.0)
[ ] Specularity exponent ('shininess')
[ ] Lighting settings

[ ] Number of lights
[ ] Their positions
[ ] Their colours (this is an easy bonus after we've done the first two)

Now that we can render 3d models nicely this suddenly got more important. In particular the darkness issue illustrated in #384 is quite annoying and would be easy to resolve with some extra light sources.


Should ariakit-react-utils re-export ariakit-utils?

Following up on #1819, I wonder if the ariakit-react-utils package should re-export all ariakit-utils modules. This way, when working on framework-specific packages (like ariakit or @ariakit/react), we don't need to figure out if some function belongs to utils or react-utils (or vue-utils, svelte-utils, etc.). We just import all utils from the framework-specific utils package.
Anyway, ariakit-react-utils hasn't defined ariakit-utils as a dependency in package.json. If we re-export everything from ariakit-utils, we need to add it as a dependency. Otherwise, we can define it either as a dependency or a peer dependency.
But I think re-exporting everything makes more sense.
cc @sarayourfriend

I'm not completely against this idea, my only concern with it is that it could potentially get confusing. I like the ergonomic benefits you mentioned but given there will probably be some differences in what is available from each of the library specific utils packages, it might get confusing trying to keep track of what is coming from the shared pool of utilities vs the view-library specific ones.
I don't think it's that big a deal, I just wanted to note it, just in case.


change vistorCount to visitorCountMsg

I was trying to build this example but got a type error.

I believe vistorCount should be visitorCountMsg.
I have also run npm test and no tests are failing.

The corresponding JS Output is correct to my knowledge.

thanks!


cmd/go: go build now builds executable under directory with same name as executable

What version of Go are you using (go version)?

$ gotip version
go version devel +cf8cc7f63c Thu Apr 4 16:10:12 2019 +0000 darwin/amd64

Does this issue reproduce with the latest release?
No, it does not reproduce with go 1.12.2.
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/mr/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/mr/go"
GOPROXY=""
GORACE=""
GOROOT="/Users/mr/sdk/go1.12.2"
GOTMPDIR=""
GOTOOLDIR="/Users/mr/sdk/go1.12.2/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/ct/bl4_z3g51ks8239_r2k07v_40000gn/T/go-build838756939=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Given a layout with files like this, noting that there a main package inside cmd/foo and a top-level directory foo:
bash-3.2$ tree -F
.
├── cmd/
│   └── foo/
│       └── main.go
└── foo/

Then running go build ./cmd/foo now creates the binary to ./foo/foo whereas it was previously rejected:
bash-3.2$ GO111MODULE=off gotip build ./cmd/foo
bash-3.2$ tree -F
.
├── cmd/
│   └── foo/
│       └── main.go
└── foo/
    └── foo*

What did you expect to see?
I expected an error like the output in go.1.12.2 about the foo directory existing, and no binary being built:
bash-3.2$ $GOPATH/bin/go1.12.2 build ./cmd/foo
go build _/tmp/x/cmd/foo: build output "foo" already exists and is a directory

What did you see instead?
A successful build that placed an executable into ./foo/foo.
I haven't bisected, but I'm guessing https://go-review.googlesource.com/c/go/+/167679/ (b48bda9c6f57ca9a940eac95700485b9640a62e9) introduced this behavior, where:

I did not specify -o
The default behavior is equivalent to -o foo
foo exists and is a directory, therefore cmd/foo's resultant binary is placed inside the foo directory

In the actual project I'm working on, I occasionally run go build ./cmd/foo to ensure that foo builds correctly, and I expect no binary to be built because the foo directory exists. I was surprised that tip actually created ./foo/foo. I would run go build ./cmd/... to achieve the same thing but there are a lot of commands in this particular project, so go build ./cmd/foo is more to the point.
Reading the comments in the CL, looking at the tests introduced in the CL, and reading through the comments in https://github.com/golang/go/issues/14295, it doesn't look like this behavior was intended.

I'll look into it.

I can confirm this behavior was introduced in that commit. I'll work on a fix.


CPU Temprature detector

Script Title - python script to get CPU temperature
Brief -
Instructions

Create a new folder for your script and file/folder name should be appropriate.
Create a README.md in your folder for program Instructions
add requirements.txt if needed

Programming Language

[x] Python

Happy Coding

Hi, I can do this
Can you assign this to me?

@pawangeek  could you check my pull request?

@pawangeek could you check my pull request?

you have to make PR here

Done ! Can u check it now?

Is this one available?

Yup it is @TheFenrisLycaon

I'd like to work on it.

@pawangeek please check and merge.


Virtualize the index route used to instantiate README.md

Currently, the index route has manually instantiate README.md as a component:
<script>
  import App from "../README.md";
</script>

<App />

Not possible through Vite.


self-hosted readthedocs issue

Hi, I've got an issue when I use self-hosted readthedocs
when rtd build on this step--> python3.6 -mvirtualenv --no-site-packages --no-download /readthedocs.org/user_builds/testrtd/envs/latest
I got an error that says --> readthedocs.doc_builder.environments:709[107]:ERROR (Build)[testrtd:latest][Errno 2] no such file or directory: '/readthedocs.org/user_builds/testrtd/envs/latest/readthedocs-environment.json'
can anyone help me out please. I've uses the docker to build.
thanks a lot!

How are you using docker? Do you mean running the whole project with docker or https://docs.readthedocs.io/en/stable/development/buildenvironments.html?

both of it, including readthedocs service and readthedocs build environments
I've use "-v /var/run/docker.sock:/var/run/docker.sock" on readthedocs service
and set the "base.py" file of "docker enable" to true,
I've read the error log, and the log tells me that it has start the container of  readthedocs build environments, but stop at
readthedocs.doc_builder.environments:709[107]:ERROR (Build)[testrtd:latest][Errno 2] no such file or directory: '/readthedocs.org/user_builds/testrtd/envs/latest/readthedocs-environment.json'
thanks again for helping me.

Here is the complete log, which hope you help me out with my problem, thanks!

I believe this is a problem with permissions, you should check if the file is created with enough permissions for the user running the docker process.
We have some problems when running docker locally in linux systems https://github.com/rtfd/readthedocs.org/pull/5556
Short story, we have the user and group harcoded in the docker file
https://github.com/rtfd/readthedocs-docker-images/blob/869edef45470331670112c36acaf4a086430d3d7/Dockerfile#L138-L142
We don't support custom installations, you can check https://docs.readthedocs.io/en/stable/support.html for other channels of support. Closing as this isn't a rtd bug, also we have the another PR to track the problem with the permissions problems in linux.


integrating conllu with NLTK?

Can conllu be integrated with NLTK?
NLTK has a ConllCorpusReader class, but it currently doesn't support CoNLL-U.
cf. conllu issue "Integrating with NLTK?" #58

@geremia: we would welcome a pull request, if you'd like to add this support


Don't copy entire send_buffer when sending a network message

Fix a huge performance penalty.

No longer needed since included in #834


Visual Studio Code shows file modified when it's not

Does this issue occur when all extensions are disabled?: Yes/No
Yes

VS Code Version:
Version: 1.57.1 (user setup)
Commit: 507ce72a4466fbb27b715c3722558bb15afa9f48
Date: 2021-06-17T13:28:07.755Z
Electron: 12.0.7
Chrome: 89.0.4389.128
Node.js: 14.16.0
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.19043

Steps to Reproduce:
This time, I opened folder "b" which has about 13 repos. I run the prettier --write . command, to format all files in all repos here. Now some files formatted and changed so I see the update. Some files are not updated though, and those are still listed and when I click to see different left and right is identical.
Also some other times I have a folder called reports. There are about 40 or so reports. Let's say we update 3 reports out of all of them. If I copy from source where I updated 3 and update all 40 in the repo, visual code registers as all 40 has been updated, but in fact 3 have been updated only.

/gifPlease

Do I need to re-create the ticket with the image?


ValidatePosition

Hi,
Looking at how you handle movements,it seems that you do not handle the Z coordinate correctly when moving without attacking : when l2creatures move, you update the X and Y coordinates but not Z, so when ValidatePosition is sent, Z is incorrect. Am I right here or did I miss something? Is using geodata the only way to fix that?
Subsidiary question: Have you taken a look at protocol 140? I'm trying to figure out the last int sent by the client in ValidatePosition. It looks a bit random even during a single move (it comes after vehicleId).

Hi.
If you referring  L2Creatures -> setMovingTo() I am afraid you are right - I am using a 2D Vector for calculating the position taking into account only X and Y. I guess I can work on this issue very soon and use 3-dimensional Vector in order to calculate X,Y and Z
Thank you

I don't really need it, but I'm wondering how things work out in places where the Z coordinates changes alot (ToI for example). Do you think averaging the Z value will be enough? Beacause using the geodata will be a pain to maintain.


Develop

Hi. How to set proxy for socketChannel ?

Hi. How to set proxy for socketChannel ?
For the answer I will present 1btc
Are you still intrested in proxy?
Tell me your telegram

@greensockss

Hi. How to set proxy for socketChannel ?
For the answer I will present 1btc
Are you still intrested in proxy?
Tell me your telegram

I can help you with this solution!


Set default content

Current behavior is that missing content is allowed, and unset content will default to "depth". This is polluting the data. This PR does not change the root cause, but stops the pollution by setting default content to "unset" instead.
Partially solve elements of #277

This needs more serious refactoring, I think. Currently, we allow for content to be given both to the class ExportData init, or later on the .generate_metadata() or .export() methods. If content is not given to the first ExportData call, it can still be given later.
This currently causes the tests to produce a lot of warnings. So not ready for merging.

OK I think I figured out what is going on here. Essentially, we issue a warning when content is not explicitly given, then default it to "depth". But this piece of code is actually never triggered, since content is defaulted to "depth" already in the initialization of the ExportData() class. Once this bug is fixed, 150-ish calls to ExportData() which are missing the content now suddenly trigger this warning. I have now added content to all of them to silence the warning.
This is under the assumption that we require content to be there for metadata to be valid.

We can (in the future) choose to not make it mandatory. Then we simply deprecate it, or stop issuing warning. However, not an option right now, because there are dependencies.
We should (in the future?) stop white-listing content, but rather issue warning rather than ValidationError, so there will be more revisits to this.

The main purpose of this PR is quick-fixing the defaulting to "depth", so that we stop polluting data.


Migrate to Material-UI v5

Material-UI v5 is on the way and will likely be a sizable migration. We want to make sure we make the migration as smooth as possible for everyone and avoid forcing migration at a particular point in time to whatever extent we can.
Let's use this issue as a point to collect and discuss ideas around how the migration can be done and when.
This is also likely to be very intertwined with #6910

@Rugvip I know this kind of question is probably asked a lot, but when do you guys plan on going stable @1.0.0? Something like this screams post-1.0.0 since it is a very breaking type change. Especially for the metric ton of plugins people have developed.

@ellisio Realized I totally forgot to reply here, sorry about that 😅
Right now we're working towards stabilization and 1.0 of the frontend core, but are excluding the component library and theming, and with that MUI. Stabilization of those parts will be a slightly later effort, but I agree that MUI v5 migration is something that should be done before we reach 1.0 there.

Beyond just planning around the 1.0 release, I think it's a good idea to have a plan for these migrations going forward, since there will be no doubt be a mui 6, 7, 8... It's an interesting issue since by having the backstage components depend on mui you take it off the market as a viable component library for those wishing to leverage something to build their own UI, unless they are ok with being pegged to whichever version backstage offers and migrating when backstage decides to.
Has any thought been given to migrating off mui as a dependency and creating custom components for backstage? I know that would present a huge amount of effort, but it might pay off in the long run in terms of avoiding churn for consumers.
In any case, I'll try to find time to help with this migration in whatever capacity I can.

I'm not sure that that problem would be any better, or even significantly different, if we made our own component library. Leaning on MUI lets us leverage their investment and knowledge around accessibility, design, customizability and many other little things, as well as tap into the huge amount of third party component libraries out there that are built on top of it. We just do not have sufficient capacity or skill set, I think, to cover a design system of that scale. I'll humbly admit that I'm convinced that at least I, personally, would surely do a terrible job of it :)

That being said, yes, you are right that this is a very important and wide contact surface that takes careful consideration. We are taking steps to ensure that the MUI dependencies are as walled off as possible, to try to keep that surface in check. But ultimately, most of the component library in the end will be using MUI semantics to some degree. Not necessarily directly - for example we have our Button and Link etc that shield things off somewhat even though that isn't their primary intent - but it's there.

@jwlawrence yep good point, and definitely a valid concern. The bump to v5 is not something we view as a one-off thing, but also as a learning opportunity for making future migrations as smooth as possible. I think one of the main things to explore here is the possibility of running multiple versions of MUI in parallel, with the intention being that that would be a temporary state that you're in during migration.
When it comes to moving to using our own component library, it's what freben said ^. I don't really think it's an area where Backstage or developer portals in general differ from other web applications. It's not until you get to a high level that there might be some components or patterns that are particularly common or well suited for Backstage, which is what core-components is about.

I'm really interested in this issue since our system is slowing down as it grows in complexity. MUI v5 offers a performance boost that is much needed. Some tests show more than 50% faster rendering.

Small update on progress.
Some significant headway has been made toward enabling this upgrade eventually; MUI dependencies have been gradually moved out of core, and the React 17 update is merged. So prerequisites are  falling into place.

Hi @freben, what's next? Need any help from the community on this?

@devth Hi! Thanks for offering - from our point of view, this is as important as it is hard. It is also not something that can be easily done in smaller pieces. It'll probably not be easy to delegate to the community at this point, but we are happy to hear of ideas or others' stories that could help us scope and plan for it a bit better. As it stands, we're considering that the maintainers would make it an explicit goal as part of some future planning, and dig down doing it as a concerted sprint effort.

Makes sense. FWIW, I recently migrated a medium sized app from MUI 4 to 5 and it wasn't too painful. Their provided codemods worked quite well and handled most of the heavy lifting.

Is there a "import patch" (not sure the right term) that maps the old imports to the new and ployfils some of the api changes? It the opposite that does the new to the old? Almost like a branching by abstraction mechanism?
I think the migration of the core packages and plugins seems doable, but it's the immediate breaking of existing applications and community plugins, and the inability to front or back load the changes it that make it challenging.

Also, introducing a code mod step in the upgrade script could help facilitate this, as well as just general upgrade changes that would be useful as things change outside of this upgrade.

Are there any updates to when Backstage will be upgraded to use MUI5?  We have some teams wanting to move their react components over to our installation of Backstage, but they were already written in MUI5.

To be honest the maintainer team likely won't have time to focus on this for the rest of the year. It's at the top of our migration list but got a lot of other things going on.
Any help would be appreciated, especially investigations into what needs to be done. For example, what happens if you try to use those MUI 5 components today? In what way do things explode? 😅

I'd also like to see what the reverse is. (if backstage core was upgraded, how could mui4 components still work)
I'd be curious what the effort to get "backstage core/proper" upgraded would be using a code mod.
https://github.com/mui/material-ui/blob/master/packages/mui-codemod/README.md#-preset-safe
One of the more annoying things would be any inflight PRs breaking.
I'd say bolting on mui5 components onto a mui4 base without a clear timeline is a bit of a non starter. maybe for a shot interval, but not as any kind of long term prescription.
If a PR was made largely using the code mod and fixing any bugs, how fast would you be willing to move on that? Would needing existing instances to be able to upgrade without upgrading their components to mui5 be a requirement?

@webark We would very much want to run the migration similarly to other big migrations, like React Router stable, where all apps and plugins can migrate at their own pace. If needed we still might set some form of deadline where we would drop support for MUI v4, but that'd likely be quite far in the future.

Wouldn't it be helpful to go back to the basics as part of the migration and use MUI across the UI so that we can take advantage of the docs, patterns, storybook, design guide, etc.? Wouldn't it make theming and other design initiatives easier?

@waldirmontoya25 what do you mean? MUI is what is used for all the UI.

@webark I meant just use MUI components. What we have seen is that not all components adhere to MUI's guidelines. Below the summary of the pain points identified:
Documentation: Team designers, as well as developers, struggle to understand what UI components are available to them and what the latest versions of those components look like because there are conflicting sources of information (MUI docs, Backstage Storybook, Backstage codebase, Backstage Figma file)
Discoverability: Waste of time reinventing the wheel because they didn’t realize the UI component they needed already existed elsewhere (e.g., in another plugin)
Quality: Some of the custom Backstage components that have been documented in Backstage’s Storybook have less functionality than similar components that MUI has already defined (e.g. alerts)
Accountability: there is currently little incentive for contributors to invest in accessibility and visual design quality before merging changes (when we first started contributing to Backstage, our accessibility audit returned 112 issues)
Theming: Hardcoded values and other deviations from MUI’s theming engine prevent entire Backstage instances from being easily themed out-of-the-box (e.g., all the buttons might turn orange except for one that stays blue)

Hi there, in the #14671 PR we're trying to sync the core components to standardize the usage of MUI (plugins tests we're updated accordingly, but each plugin should adhere to the Component Design Guidelines in a different PR), hopefully this helps with the issue mentioned before about components not adhering to the guidelines, as well as make migration easier.
At VMWare we're interested on the V5 upgrade work, based on this issue's discussion the main points would be:

Partial upgrade: Can't find any docs around something like this, in fact I would consider it a bad thing, what if we forget to update a part of the codebase because how big it is? more so with the codemods officially setup by MUI to handle the migration, it should be simpler to just run the codemods on the whole project, fix the issues and then instruct the plugin authors/maintainers to refactor the result to make sure the theme still looks ok, then instruct any Backstage instance admin to run the codemods and fix any custom implementations they have.

Codemods: We should rely on MUI codemods as much as possible, then if we see there's a repeatable pattern of fixes we(maintainers, plugin authors or users) have to apply after MUI codemods, then we can think of creating custom codemods (if any necessary) to bridge the upgrade process.

V4 Theme: @webark mentioned V4 & V5 themes being incompatible, however there seems to exist an adaptV4Theme helper which should bridge that at the start, off course we should eventually remove the helper to use a V5 compatible theme.

Tests: As far as I've seen while working with @backstage/core-components the tests do not rely on anything specific to MUI, we query components by text content (as recommended by React), and that will pay out in this update, I would expect minimal changes to tests in the update, any issues in tests would happen around build issues after running the codemods.

Storybook: The Storybook has been outdated for some time, some components do not have stories, and those that do are overly simplistic, I want to note having a well supported storybook would help on checking the before and after update to make sure the update didn't introduce UI changes that the tests can't catch, since we could compare the Backstage's Figma page with the actual implementation in the Storybook.

Core & Plugins but no Instances: Stand to reason we should not involve ourselves with specific user instances other than pointing to MUI upgrade docs & providing custom codemods (if needed), the question here would be if a first PR should only care about the core packages or should we also target the plugins, feel like other than the codemod run  we should not touch plugins as long as the tests are running properly, we (or any other maintainer) would lack context in each plugin to apply any refactors or fixes.

Am I missing anything?

I was going to go back and try to fiddle with it, but the theme only partially came over. Also the way that you reference nested classes changed as well, and so did the override mechanism. I didn't spend any time fiddling with that, but only getting all the deps correct and trying to get the tests passing.

You mean CSS classes for nested components right? so the codemods weren't able to change the class nesting and overrides properly? do you have a branch to look at? I'm going to try myself tomorrow and see the issues pop up.

Yea. This https://mui.com/material-ui/migration/v5-style-changes/#migrate-theme-styleoverrides-to-emotion

And i didn't push a branch. I just have it on my local still

+1 for not wrapping MUI.
The MUI project has incredibly high standards, momentum, and a massive community to support high quality, consistency, up-to-date docs, storybooks, tests, and thoughtful APIs that expose the right controls to the end user.

A year ago people were discussing doing this before 1.0, that's already shipped off so, are we going to mark this for a 2.0 release?

In regards to not wrapping MUI components, what components are you talking about specifically? Things like the "info card" or the layout ones like "page" and "header"? Or like Links and buttons..

As far as I see (can't be sure all the @backstage/core-components follow this) Backstage doesn't wrap the MUI components, it presents reusable abstractions (DRY principle) that Backstage expect plugin developers & app admins to use more frequently (be it only style abstractions or feature ones).
However Backstage doesn't forbid the use of MUI components, it recommends using the core components whenever possible, and then we can use the MUI components if none core ones fit our needs plugin-development#developing-guidelines.
Case in point InfoCard component does use the MUI card under the hood, but adds styles as well as some extra features like ErrorBoundary and BottomLink, so I wouldn't say InfoCard is a wrapper of MUI's Card.

There are a chunk of the core components that just have a storybook in it. Maybe that's what you are mentioning?

There are some that don't, there are some that have a single story without any kind of support for Storybook Controls nor Storybook Actions, and then there are some with either partial or proper support.

Tried the update, steps are simple but the sheer amount of changes is hard to deal with, more than 1000 file changes (mostly thanks to the MUI codemods & yarn workspaces foreach to change deps in all packages & plugins), the issues are the breaking changes that the codemods can't handle, checking & fixing the build errors just takes a lot of time...

Do we have a way going forward with this?

not completely? I kind of want to find a window sometime, where we can kind of pause the work on the rest of the front end plugins and packages, and put focus on getting this out. Its just becoming more and more of a wart. It's just going to be very disruptive from a files changed perspective, and i'm not sure on the feasibility of having both be used simultaneously.
There are some places that we could do some prep work to get ready for it. I think @luchillo17 did some work recently in that area.

I spent a bit of time towards this to see if we could get it kickstarted. Proposing a way forward for this in #15484. I think we can get simultaneous v4 + v5 support going, and to be honest we really need to be able to make this an incremental migration. There's way too much potential work to migrate to v5 that we can't force it as part of a single release. I do think we want to make it somewhat fast though, within 6 months or maybe less. The TypeScript performance seems to take a pretty big hit when running v4 and v5 at the same time. It's either that or we figure out a way for projects to completely drop v4 when they can.

Thanks so much for working on this! I know this whole process is a bit of a drag all around :/
Is there a way we could just have an optional theme provider for those that want to have both v4 and v5 running simultaneously? Most consumers could probably handle the migration within a couple of weeks as the updates after running the code modes are pretty light aside from the theme work. And having the unified theme be an opt in would give more flexibility for upgrading?
And are you saying upgrade the backstage repo within 6 months? or have the option of running bother only be supported for 6 months.
Thank you again. I know these kinds of situations there's no great solution.. :/

@webark i think the most sensible option is gonna be to make v4 support optional, based on whether v4 is present or not. I'll likely take a stab at that once I spend some more time on this. Basically if v4 isn't installed we won't bother creating a theme for it.
Regardless of how fast people upgrade their own projects there's going to be plenty of usage of other OSS plugins that need to be migrated too.
The 6 months would be the window that we support v4 at all, although tbh if that support is lightweight and out of the way we can probably keep it for longer.

Yea. community plugins are the long tail effort in my opinion. As long as backstage proper doesn't get stuck in the limbo of both, then I think this plan is 🤩

We should make a distinction between supporting MUI v4 & supporting MUI v4 theme, there's a theme adapter so a V4 theme can be used with MUI v5, @Rugvip when you say v4 + v5 support you mean the themes or the actual MUI codebase & components?

I had a quick look at this migration GitHub issue and related PR. What I noticed:

React 17 was a friction point. It's now solved. Maybe MUI shouldn't have made it a requirement https://github.com/mui/material-ui/pull/35232#discussion_r1030906426.
Being able to run v4 and v5 at the same time is critical for Backstage. Both because it's impossible to migrate everything to a working state in one PR and because of the community plugins that need a smooth upgrade path, a la WordPress. On this, it seems that MUI could improve:

The migration docs, and document how to run v4 and v5 in the same codebase. using https://mui.com/x/react-data-grid/migration-v4/#using-mui-core-v4-with-v5 as inspiration. It should be before any of the imports are updated https://mui.com/material-ui/migration/migration-v4/#replace-all-imports. The current migration v5 docs only works with small projects.

Expose backward compatibility adapters. I saw the opposite adapter to adaptV4Theme was created. It's something MUI could expose (using a v5 theme with v4 components).

Anything else?

@luchillo17 @testn v4 + v5 support means both theme as well as codebase and components, i.e. you should be able to use components from for example @material-ui/core and @mui/material in the same app. I've spent some time digging into different ways of loading in the different MUI versions as weak dependencies in the theme package. It adds a bit of complexity but it might be something we end up going with. There are a couple of different points in the migration where it would be beneficial to support weak deps:

Phase 1: Initial MUI v5 support

In this first step we add the ability to use the v5 theme, and to start using v5 components. At this point it would be beneficial to have MUI v5 be a weak dependency in order to only add the overhead for users that want to get out ahead of the migration.

Phase 2: Simultaneous v4 and v5 support

The next step is to start migrating all Backstage packages (both @backstage/* and external) to MUI v5. At this point we will require support for both MUI v4 and v5. We won't aim to migrate all packages within a single release cycle. There overhead of running both versions will be present in all apps that upgrade to these versions.

Phase 3: Optional v4 support

Once all packages used within a given app have been migrated to MUI v5, it should be possible to drop support for MUI v4 in that app. At this point we want it to be possible to have MUI v4 be a weak dependency in order to not add the overhead of running MUI v4. Once a given app reaches this state it has completed the MUI v5 migration.

I'd say that the main thing to consider is whether we want to try to make MUI v5 optional during Phase 1, as this would avoid the overhead of v4 + v5 for one release cycle (1 month). I've run some simple benchmarks to get an idea of what the overhead is like for adding MUI v5 to an existing app with MUI v4:

example-app in this repo:

yarn build: 29.541s +1.79s ~6.44%
yarn tsc:full: 58.376s +3.38s ~6.14%

Newly created app from @backstage/create-app:

yarn build: 18.085s +0.57s ~3.25%
yarn tsc:full: 11.743s +1.66s ~16.44%

I feel that these numbers are fairly reasonable, as in I don't think it's worth adding a lot of complexity in order to avoid this overhead for one release cycle. If we can achieve it with relative easy without complicating phase 2 it's probably worth it though.

@oliviertassinari Thank you for having a look! 🙏
Regarding React 17 we support both v16 and v17 right now, although we've been shipping v17 as the default for a long time now, and only test towards v17. Given that we also want to move on to v18 we'll likely drop support for v16 soon. It would be nice not to be forced to do that as part of the MUI migration though, as it stacks two migrations on top of each other. We can of course drop v16 support first though, perhaps even as part of phase 1, mentioned above.
👍 for updating migration docs to mention simultaneous use of v4 and v5, I did look around quite a bit for that and couldn't find those docs.
Same thing for the v5 -> v4 adapter, would be sweet to have an official one.
There is one more thing I ran into, which is https://github.com/mui/material-ui/issues/35287. The workaround is baked into the v5 types, but it's always a bit ugly to ship those kinda global types: https://github.com/backstage/backstage/blob/bd63a210c19359c4307b91d08e0b975b151e5936/packages/theme/src/v5/types.ts#L39-L48
I'd wonder if there's something that could be done with conditional types in MUI v5 to avoid the issue?

Phase 2 would also be the timeframe for public plugins to migrate, right?
If they wanted to support both v4 and v5, they'd need some sort of dot releases, and release a v4 and a v5 independently?
Might be good to suggest some best practices for this?

@Pike yep, I don't expect plugins themselves to have the need for any form of simultaneous support though. Once we guarantee that v5 theming is available in the app, any plugin would be free to migrate to v5. Whether a plugin is partially of fully migrated hopefully shouldn't be visible from the outside. It simply uses either v4 or v5 components internally.

Phase 1: Initial MUI v5 support

In this first step we add the ability to use the v5 theme, and to start using v5 components. At this point it would be beneficial to have MUI v5 be a weak dependency in order to only add the overhead for users that want to get out ahead of the migration.

Phase 2: Simultaneous v4 and v5 support

The next step is to start migrating all Backstage packages (both @backstage/* and external) to MUI v5. At this point we will require support for both MUI v4 and v5. We won't aim to migrate all packages within a single release cycle. There overhead of running both versions will be present in all apps that upgrade to these versions.

@Rugvip Would it be possible if phases 1 and 2 are combined and provide an escape hatch for people who don't need v4?

@Rugvip So, I guess we have to wait until https://github.com/backstage/backstage/pull/15484 gets merged so we can start contributing to plugin migration, correct?

@waldirmontoya25 yep!

https://github.com/material-table-core/core/releases/tag/v6.0.0 :/

@webark yep we saw this coming and it's another motivation for us to push the muiv5 migration. Hoping to get this prioritized H1 this year.

@Rugvip Thanks for the feedback on what Material UI could do to improve the upgrade experience. I had a look at t he type issue, I proposed a solution in: https://github.com/mui/material-ui/issues/35287#issuecomment-1408870399.

The customization issue highlighted in #16631 should be taken into consideration for this. In particular if we decide to change or add recommendations for how components are styled, we should make sure those recommendations are compatible with the theming system.

Hi @Rugvip, I could swear I saw somewhere mentioned that this was going to be worked on for the June release - 1.15.0 - can you confirm or is that just my imagination?
We have some desire to use our internal components but they are all on MUI v5 and because of that have some resources that would be able to help

@awanlin yep @tudi2d has spent some time to get #15484 in a shippable state, as well as a few followup migrations. If all goes well we'll ship it into next straight after the main line release next week

Awesome thanks for the update @Rugvip and @tudi2d for pushing it forward some more.

Hi guys! Could you provide some specific date when you plan to release the migration? Thanks a lot!

Hi @ypetrych, given all the things still in-progress and summer vacation it would not be wise for us to share a date or tentative release for this. We should be better able to answer this towards the end of summer. One part that is slowing things down is getting the React 18 upgrade completed. There's an RFC around that you might want to read: https://github.com/backstage/backstage/issues/18625
That said, if is important to you then if you are on version 1.15.0 or newer you can do this already. You need to upgrade to at least React 17 but I'd recommend going to React 18. From there you can update to using Material UI v5 following their migration guide: https://mui.com/material-ui/migration/migration-v4/. Keep in mind that there may be issues that we have no encountered yet. The organization I work for has done this and so far it's been solid for us but we are a mid-sized so there's a chance we did not hit some unknown pain points. I would say the part that required the most work was fixing and updating tests.

Is there existing documentation around the need to use the v5- class prefix for overriding styles? Or are we using the local overrides wrong and shouldn't be needing this.

@tudi2d Is it the same for overwriting sub items at a component level?
When using the "sx" property, we had to add the "v5-" for them to get picked up. Should we not have to even when it's individual components? (not at the theme, at the ex property)

now that users can migrate to mui V5 what about the sx support and finally remove the makestyle

So, this issue is quite old and there's already MUIv6 available. Is the migration going to be from 4->5 or straight from 4->6? And are there any timeline for this, perhaps in relation to the new frontend system?

From what have heard they are focusing on the Migrating completely to the new backend and front end first, Then this will be a cleaner migration.
We use a lot of MUI 5 components, and are at mui 5.16 currently without issue. The main annoyance for us is the material table core, but we are thinking about redoing our main tables with a more modern library that works either graphql better.

We're actually looking into this atm 😁, goal is to make sure that MUI v5 and v6 adoption is properly supported, bugs are ironed out, and with a path to completely be able to remove MUI v4 at some point. For now the best place to track it is in the MUI v5 milestone still, linked in this issue.

One issue we found is that MUI 5 supports react >= 17, while there's a check that peer deps in main include react 16. Should this be changed to allow migrating plugins?


Conceptual confusion between Aggregates and Owned Entities

Hi,
The second paragraph states that:
> Owned entities... ... are conceptually similar to aggregates.
But... Owned entities are the way to implement Value Objects, because they don't have an identity of their own, while Aggregates do have an identity, as a part of their key fundamentals.
So they're actually completely different, by large.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: d02e6748-42e0-000a-4945-42cd05a0b875
Version Independent ID: e3effbd0-07f2-423d-4032-1722e75adb37
Content: Owned Entity Types - EF Core
Content Source: entity-framework/core/modeling/owned-entities.md
Product: entity-framework
Technology: entity-framework-core
GitHub Login: @AndriySvyryd
Microsoft Alias: ansvyryd

@mvelosop This is basically true--see https://github.com/aspnet/EntityFrameworkCore/issues/17836#issuecomment-565786234


Release 3.1.0

There are other approved PRs that could be included as well.

@ST-DDT Thank you for your reminder. I will take a look and consider including the other approved PRs as well.

I have already handled several PRs, but I'm not quite sure about these three remaining ones. Do you have time to review these PRs?
Another option is to include them in the next release version.
@fengli79 @DNVindhya @stanley-cheung


ready vs initial add events with awf

Hi,
when the awaitWriteFinish option, the ready event is fired before the add events for files that already exist on the watched space. Do you think it's normal? I'd have expected ready to be fired only after all the add events.

awaitWriteFinish suppresses any add events based on its parameters of polling for file size changes. Perhaps this should be changed to not take effect until after the ready event though.