I am a citizen developer and have very little software development background. The SharePoint Dev Platform environment setup is:

(1) Too complicated (installing node.js, gulp, yeoman, dev certificates etc)
(2) Fills me with fear (e.g. using npm to download hundreds of files from unknown places)

SharePoint is a Microsoft product, development for which should be handled by a development environment installer such as Visual Studio Community Edition. Within Visual Studio Community Edition I should just be able to click 'SharePoint Framework' and the environment should then be setup to support SharePoint Framework development. No command line, no going off to random websites to install software I have no idea about.

I would trust Visual Studio Community Edition to setup my development environment much more than random command line commands.

Make SharePoint Framework development easier (and less anxiety generating!) for citizen developers.

SYMPTOM:
- O365 user sfox@kellylyonslaw.com receives and email
- She then copies (drags / drops) that email into SharePoint Company Docs folder.
- If the email message is viewed in SharePoint, the date is +7 hours (which is GMT from Arizona). That is, it reflects a 7-hour difference on when the email was received in Outlook
- As part of diagnoses we have looked at the Email Properties (header) itself within the Outlook 365 Desktop App
- The Email properties / headers reflect that the Item was received with the same +7-hour difference, too
- We have verified that the Global SharePoint time zone is correct
- We have verified that the user time zone settings are correct (Computer time; Outlook Web settings)

TO REPRODUCE ISSUE:
- Drag and drop a message from Outlook web or Outlook app (Windows) into SharePoint document area.
- View email message in SharePoint. The time stamp on the message is 7 hours different from Arizona time (which is out set time zone)
- (Doing reverse steps) If the affected message is downloaded from SharePoint, and then opened in Outlook, the time is correct again
- RESULT: SharePoint viewing of email messages shows incorrect time. Seems to reflect GMT

WHY IS THIS IMPORTANT?
- The lawyer firm needs to be able to prove when emails are sent and received. An error of 7 hours could cause a significant disruption in a court case

I'd like to be able to have one web part that shows or hides another web part, or a web part that can contain other web parts. The system has section layouts, now, but I'd like to take that a step further.

This comes up because I've been looking for a solution to have a SharePoint modern page that can switch between two different views to a document library - a custom web part, and the standard web part. When I was trying to find a modern solution, I did see that older versions of sharepoint have had a fairly well known "hilbilly tabs" solution that seems to do something like this.

I suppose I might be able to do this with custom javascript, but it seems like it would get ugly and not be using supported features.

Ideally, I'd have a "layout" option isntead of one column, two columns, etc., which could have tabs or some kind of switch to completely disable one of the web parts and render the other one.

Hopefully it's already possible, but I just haven't found a way how yet.

Expanding on the WebPartFormFactor concept, it would be great to be able to natively get information about the size of the current web part zone hosting the web part. This would allow us to more easily offer optimised UX based on how the web part is being displayed (eg: if the web part is in a 1/3 or 1/2 width zone, show fewer items per row than if it's full-width).

This can currently be achieved with native JS measuring element widths and resize handlers, but it'd be much cleaner and more reliable to have native integration, especially as more layout options are added.

TSLint is deprecated nowadays as ESLint supports TypeScript. However, we cannot replace TSLint with ESLint in SPFx projects because TSLint task is a part of the build process internally. It would be nice to use ESLint by default.

A couple of GitHub links about the topic:
- https://github.com/SharePoint/sp-dev-docs/issues/4972
- https://github.com/microsoft/rushstack/pull/1592

A couple of interesting historical facts:
“In fact, it all started a long time ago: the last release of the tslint kernel was already in 2016. And this is the moment when it is time to start saying “last,” if someone still says “last,” because that release was really the last. On February 19, 2019, an official post was released to stop the development of tslint. In it, the development company (by the way, it’s not even Microsoft) strongly advises everyone to switch to eslint, since their efforts will now be aimed at improving TypeScript support in this linter.”

“...[Microsoft] wrote a migration plan. In accordance with this plan, the development of tslint rules has already been discontinued on August 1, 2019, and the development of tslint itself will cease on November 1, 2019. Although, to be honest, development has been discontinued a long time ago (see above for the latest release).”

Source: https://prog.world/the-horse-is-dead-cry-transition-from-tslint-to-eslint/

We need an automated Flow for Collect Feedback to replace the Collect Feedback SharePoint 2010/2013 Workflow. I need to route Office documents--specifically, Microsoft Word, or Visio Drawings, Powerpoints, or spreadsheets, to stakeholders (Engineers) for their feedback. Specifically, these are procedure documents that require redlines (Tracked Changes) and the ability for the reviewer to edit/add comments. Word already does that, yes, but I need to be able to run a SharePoint Workflow that is NOT an Approval workflow. It's to be used for collecting redline feedback, reviews, tracked changes, and routing to several users. Not including that Collect Feedback Workflow in PowerAutomate is absolutely killing my division's procedure projects. In a bad way.