cbc28e8e33
(extracted from #23678) * Move Wizard back into main app, remove Wizard addon * Remove Wizard-related resolver or build hacks * Install and enable `@embroider/router` * Add "wizard" to `splitAtRoutes` In a fully optimized Embroider app, route-based code splitting more or less Just Work™ – install `@embroider/router`, subclass from it, configure which routes you want to split and that's about it. However, our app is not "fully optimized", by which I mean we are not able to turn on all the `static*` flags. In Embroider, "static" means "statically analyzable". Specifically it means that all inter-dependencies between modules (files) are explicitly expressed as `import`s, as opposed to `{{i18n ...}}` magically means "look for the default export in app/helpers/i18n.js" or something even more dynamic with the resolver. Without turning on those flags, Embroider behaves conservatively, slurps up all `app` files eagerly into the primary bundle/chunks. So, while you _could_ turn on route-based code splitting, there won't be much to split. The commits leading up to this involves a bunch of refactors and cleanups that 1) works perfectly fine in the classic build, 2) are good and useful in their own right, but also 3) re-arranged things such that most dependencies are now explicit. With those in place, I was able to move all the wizard code into the "app/static" folder. Embroider does not eagerly pull things from this folder into any bundle, unless something explicitly "asks" for them via `imports`. Conversely, things from this folder are not registered with the resolver and are not added to the `loader.js` registry. In conjunction with route-based code splitting, we now have the ability to split out islands of on-demand functionalities from the main app bundle. When you split a route in Embroider, it automatically creates a bundle/entrypoint with the relevant routes/templates/controllers matching that route prefix. Anything they import will be added to the bundle as well, assuming they are not already in the main app bundle, which is where the "app/static" folder comes into play. The "app/static" folder name is not special. It is configured in ember-cli-build.js. Alternatively, we could have left everything in their normal locations, and add more fine-grained paths to the `staticAppPaths` array. I just thought it would be easy to manage and scale, and less error-prone to do it this way. Note that putting things in `app/static` does not guarantee that it would not be part of the main app bundle. For example, if we were to add an `import ... from "app/static/wizard/...";` in a main bundle file (say, `app.js`), then that chunk of the module graph would be pulled in. (Consider using `await import(...)`?) Overtime, we can build better tooling (e.g. lint rules and babel macros to make things less repetitive) as we expand the use of this pattern, but this is a start. Co-authored-by: Godfrey Chan <godfreykfc@gmail.com> |
||
|---|---|---|
| .devcontainer | ||
| .github | ||
| .vscode-sample | ||
| app | ||
| bin | ||
| config | ||
| db | ||
| docs | ||
| documentation | ||
| images | ||
| lib | ||
| log | ||
| migrations | ||
| plugins | ||
| public | ||
| script | ||
| spec | ||
| test | ||
| vendor | ||
| .editorconfig | ||
| .eslintignore | ||
| .eslintrc.cjs | ||
| .git-blame-ignore-revs | ||
| .gitattributes | ||
| .gitignore | ||
| .jsdoc | ||
| .licensed.yml | ||
| .licensee.json | ||
| .npmrc | ||
| .prettierignore | ||
| .prettierrc.cjs | ||
| .rspec | ||
| .rspec_parallel | ||
| .rubocop.yml | ||
| .ruby-gemset.sample | ||
| .ruby-version.sample | ||
| .streerc | ||
| .template-lintrc.js | ||
| Brewfile | ||
| CODEOWNERS | ||
| config.ru | ||
| CONTRIBUTING.md | ||
| COPYRIGHT.md | ||
| d | ||
| discourse.sublime-project | ||
| Gemfile | ||
| Gemfile.lock | ||
| jsconfig.json | ||
| lefthook.yml | ||
| LICENSE.txt | ||
| package.json | ||
| Rakefile | ||
| README.md | ||
| translator.yml | ||
| yarn.lock | ||
Discourse is the online home for your community. We offer a 100% open source community platform to those who want complete control over how and where their site is run.
Our platform has been battle-tested for over a decade and continues to evolve to meet users’ needs for a powerful community platform. Discourse allows you to create discussion topics and connect using real-time chat, as well as access an ever-growing number of official and community themes. In addition, we offer a wide variety of plugins for features ranging from chatbots powered by Discourse AI to functionalities like SQL analysis using the Data Explorer plugin.
To learn more, visit discourse.org and join our support community at meta.discourse.org.
Screenshots
Browse lots more notable Discourse instances.
Development
To get your environment set up, follow the community setup guide for your operating system.
- If you're on macOS, try the macOS development guide.
- If you're on Ubuntu, try the Ubuntu development guide.
- If you're on Windows, try the Windows 10 development guide.
- If you're looking to use a simpler Docker-based install, try the Docker development guide.
If you're familiar with how Rails works and are comfortable setting up your own environment, you can also try out the Discourse Advanced Developer Guide, which is aimed primarily at Ubuntu and macOS environments.
Before you get started, ensure you have the following minimum versions: Ruby 3.2+, PostgreSQL 13, Redis 7. If you're having trouble, please see our TROUBLESHOOTING GUIDE first!
Setting up Discourse
If you want to set up a Discourse forum for production use, see our Discourse Install Guide.
If you're looking for official hosting, see discourse.org/pricing.
Requirements
Discourse is built for the next 10 years of the Internet, so our requirements are high.
Discourse supports the latest, stable releases of all major browsers and platforms:
| Browsers | Tablets | Phones |
|---|---|---|
| Apple Safari | iPadOS | iOS |
| Google Chrome | Android | Android |
| Microsoft Edge | ||
| Mozilla Firefox |
Additionally, we aim to support Safari on iOS 15.7+.
Built With
- Ruby on Rails — Our back end API is a Rails app. It responds to requests RESTfully in JSON.
- Ember.js — Our front end is an Ember.js app that communicates with the Rails API.
- PostgreSQL — Our main data store is in Postgres.
- Redis — We use Redis as a cache and for transient data.
- BrowserStack — We use BrowserStack to test on real devices and browsers.
Plus lots of Ruby Gems, a complete list of which is at /main/Gemfile.
Contributing
Discourse is 100% free and open source. We encourage and support an active, healthy community that
accepts contributions from the public – including you!
Before contributing to Discourse:
- Please read the complete mission statements on discourse.org. Yes we actually believe this stuff; you should too.
- Read and sign the Electronic Discourse Forums Contribution License Agreement.
- Dig into CONTRIBUTING.MD, which covers submitting bugs, requesting new features, preparing your code for a pull request, etc.
- Always strive to collaborate with mutual respect.
- Not sure what to work on? We've got some ideas.
We look forward to seeing your pull requests!
Security
We take security very seriously at Discourse; all our code is 100% open source and peer reviewed. Please read our security guide for an overview of security measures in Discourse, or if you wish to report a security issue.
The Discourse Team
The original Discourse code contributors can be found in AUTHORS.MD. For a complete list of the many individuals that contributed to the design and implementation of Discourse, please refer to the official Discourse blog and GitHub's list of contributors.
Copyright / License
Copyright 2014 - 2023 Civilized Discourse Construction Kit, Inc.
Licensed under the GNU General Public License Version 2.0 (or later);
you may not use this work except in compliance with the License.
You may obtain a copy of the License in the LICENSE file, or at:
https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
Discourse logo and “Discourse Forum” ®, Civilized Discourse Construction Kit, Inc.
Accessibility
To guide our ongoing effort to build accessible software we follow the W3C’s Web Content Accessibility Guidelines (WCAG). If you'd like to report an accessibility issue that makes it difficult for you to use Discourse, email accessibility@discourse.org. For more information visit discourse.org/accessibility.
Dedication
Discourse is built with love, Internet style.